MML: The Summation

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

[-- Attachment #1: Type: text/plain, Size: 1832 bytes --]


To prematurely sum up the pros and cons of using MML (or something
similar) for Message's MIME interface:

Cons:

1) You can't expect people to learn a markup language.
2) MML is ugly.
3) Inband marking of elements is bound to fail.  Look at the breakage
   done by sendmail's "From " separator.

Pros:

1) I like languages, not applications.
2) MML is cute.
3) Doing MIME is dull, boring and tedious.  By having a simple markup
   language that gives us the power of MIME without the bogosity,
   anyone can write scripts that do MML, which can then just be
   pushed to Message for Mimification.
4) Doing it in a non-textual way (text props, overlays, markers,
   invisible text) sucks because it doesn't allow the users
   to edit the stuff properly.  What if you are composing a complex
   MIME thing in one buffer, and then you decide to copy the text
   to a different buffer?  

That's basically it.  I like the idea of just saying

<#part>
And then writing some Chinese text, and then saying

<#part>
And write some Japanese text, and then saying

<#part type=image/jpeg filename="~/rms.jpg">--==-=-=




to include an image.  If I don't like the order of these paragraphs, I 
can just use the normal Emacs editing tools (C-k, C-y) and move them
wherever I want to -- up, down, to another buffer, or just kill them
altogether.

I think MML gives us the flexibility to compose any MIME message, in a 
very low-impact way.

Of course, one doesn't necessarily have to have just one interface.
For instance, the trivial "include this attachment with this mail" can 
be handled using a different mechanism -- for instance, a header line
`X-Attachment: type=image/jpeg filename="~/rms.jpg"' can be used in
these trivial cases.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen