My implementation of header-set does not work that way. The model that
header-set fits is "here is some extra stuff that goes with this data".
It's relatively easy to cache the "extra stuff" (or even do the right thing
with the extra stuff) before reading the data.
It sure is nice if you're able to implement this cleanly. Unfortunately, I have
a real problem with this, since interfaces I don't control insist on me telling
them what's going on before I'm ready to. This means than in order to implement
this I effectively have to pick up the entire multipart structure and shunt it
off somewhere, examine it, and then back up and retry it once I know what's
going on.
Implementation of this isn't particularly difficult since I have all the MIME
parsing code I could ever need. It sure is ugly, though, and the overhead is
quite large.
At 8:36 PM 10/25/93 -0400, Nathaniel Borenstein wrote:
a big win for metamail, which wants to be able to do everything in one
pipe-like pass through a MIME message. This is not at all possible
with header-set. It is closer to possible with multipart/related,
My situation is that I'm at the back end of a MIME pipe and at the front-end of
another sort of pipe. Data is written to me in arbitrary chunks. I have to
process each chunk and return to my caller, saving whatever state I'm in at the
time. In the meantime I have to communicate my wishes to the next part down the
line at appropriate points in the process.
I, too, make one big pipe-like pass through a MIME message. I found (to my
delight) that multipart/header-set took NO code changes at all over how I
was handling multipart/foo.
I suspect this is a result of having planned to deal with appledouble from the
start as the rule rather than the exception.
My multipart handler has always delayed its decision on what to do with a
multipart until it read the first part. It was simpler to code that way,
and provided a bit of failure handling as well (in case multipart/foo had
the wrong parts, this allowed me to fall back to multipart/mixed handling).
Multipart/references scares the heck out of me on this ground, because I do
not know until I get to the "start" part what the pieces mean. I *must*
save them separately, and go back to them later, unless the "start" part is
at the beginning.
Agreed. I think we should stick with having the header first unless there is
some compelling reason to move it.
Multipart/references becomes less scary for me if the start parameter is
eliminated and the first part is used as the start part. I can read and
digest the start part, and know in advance what I must do with the other
parts.
I see this as functionally the same as header-set.
Yes, if the start part represents a compound document instead of the
simpler attributes-for-data kind of thing, the reader may have to wait to
display the start part until the body parts are read, and this may require
caching the start part to a temporary file or in memory. But I suspect
that (more often than not) the start part is going to be significantly
smaller than the data parts, and so this will be less of a problem than the
other way around.
Size is less of an issue than complexity for me.
Ned