Ok, let's discuss a little bit before my head explodes (and my wife
calls me for dinner ;-)...
The thing we need first in mailcap format, in my opinion, is a
discrimination by parameter's value for each entry.
As an example, the composition command of a text/plain may
seriously vary in function of charset's value. A "us-ascii"
text could use the builtin user interface widgets and a
"iso-8859-8" could use an external post-processor in order
to translate latinized (us-ascii) hebrew into hebraic characters
in the corresponding charset. I know that this can be managed by
view-commands, compose-commands, and so on but this is not easy
to use in a tool which does not want to count on external viewers/
composers. And my (maybe yours too ?-) goal is to build/use a really
wysiwyg mime MUA pluggable into a brand new computer with just OS
on it and nothing else.
I think that two main ways are possible :
1) associate a mailcap entry to each parameter's variation. This can
be the byte-greediest solution but I think it's the simplest to implement
from the existing mailcap format.
2) integrate in each entry a way to switch (as a C statement) in
function of a paremeter's value. This is nicer but also more
complicated.
Example case 1:
text/plain; cat %s; \
parameter=charset STRING "us-ascii"; \
compose=bla-bla-something; \
copiousoutput
text/plain; heboutput %s; \
parameter= charset STRING "iso-8859-8"; \
bla-bla-bla
Example case 2 :
message/external-body;
parameter=access-type ENUM {"ftp", "anon-ftp", bla, bla }; \
parameter=name STRING; \
parameter=site STRING;\
...
case (access-type="ftp", bla-other, bla-conditions) \
view=...;\
compose=...;\
end; \
case (access-type="anon-ftp", bla-other, bla-conditions) \
view=...;\
compose=...;\
end; \
Still thinking aloud and waiting for your reactions (I hate time shifts).
BTW, how will a tool make the difference between a "old format" mailcap and a
new one if any ?
</Daniel>