Re: Content-Disposition Header and multipart/alternative

[Nathaniel Borenstein <nsb@xxxxxxxxxxxxxxxxxxxx>]

Excerpts from mail: 29-Jun-93 Content-Disposition Header .. Rens
Troost@stimpys.imsi (3133)

> Nathaniel, you raised a point about the hidden disposition type being
> difficult to deal with in linear (metamail-style) parsers. Isn't this
> also a problem with multipart/alternative, in which the 'richest' of
> the alternatives comes last? You have to scan all the alternatives
> before falling back to the first, simple one.

Bang.  You got me.  I wasn't mentioning this because I didn't want to
complicate the discussion, but...

As it turns out, when I was first writing metamail, I had this  funny
feeling that I better code more carefully than usual; just an instinct,
I guess, that lots of people would see this code.  And I was actually
very happy with the way the code looked until one fateful day, about two
years ago, when someone on the list convinced me that the then-specified
order of multipart/alternative should be reversed, yielding the
"best-version-last" semantics we have now.

That change KILLED metamail's structural integrity.  I should have done
a completely rewrite at that point, but didn't have time.  If you look
through the metamail code for "SquirrelFile", you'll get an idea of how
bad it was -- SquirrelFile was added strictly to accomodate the
"best-version-last" semantics of multipart/alternative.  I still cringe
every time I look at it.  If we add the kind of semantics that have been
discussed for 'hidden', I would have to either make it much worse or
rewrite it completely enough to make it much better, and guess which one
I'm more likely to have time for....  

> This has to be dealt with, it seems to me, whether you use
> multipart/alternative or a hidden disposition.

Yeah, the one advantage is that people have already implemented or are
already implementing multipart/alternative, so "hidden" simply adds
complexity.....

> That said, I'd be more than willing to jettison "hidden" in favor of a
> reccommendation to use multipart/alternative in this manner. It's a
> good clean solution to the problem; good call, Gabe!

> Is this agreeable to y'all?

It is certainly extremely agreeable to me!  -- Nathaniel