[Top] [All Lists]

Re: yet another way to indicate related MIME body parts

1993-10-26 08:51:36
At  9:43 PM 10/25/93 -0400, Keith Moore wrote:
You have to store the messages anyway to allow arbitrary cross-referencing.

At this point in time, I don't support arbitrary cross-referencing.  All I
need to implement what I'm interested in (Macintosh file transfer) is the
ability to do a very limited sort of cross-referencing; namely, the
association of some sizeable attributes with a file.

It seems like multipart/references makes this simple task much more complicated.

Now, perhaps the arbitrary referencing of multipart/related is so insanely
useful that I should make it possible anyway, and then let appledouble just
fall out of it.  However, at this point, I am unconvinced that this is so
(real-world examples might help).

On the other hand, it seems like any practical implementation of header-set
would need that also, just so that the module that processes the first
component of the header set would be able to read the other components.

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.

Consider AppleDouble: the header part is the "resource fork" and file type
information.  I see this, I create the file, apply the type, dump the
resource fork stuff into the file's resource fork.  Now, for the data part,
I just open the data fork and write the contents.  The only special
handling required for the data part is to remember to use the same filename
as for the resource fork.

Or UNIX permissions: the header part is (eg) uid, gid, and permissions.  I
create the file, set the permissions.  Then for the data part, I just dump
in the data.

In neither of these (admittedly simple; that's what header-set is good at)
examples was it necessary to have the data in hand before processing the
header part of the header-set.

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,

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.

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.

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

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.

While putting the start part first would help, I still prefer the
simplicity of header-set for simple problems like AppleDouble.  Header-set
gives me a multipart and two body parts, whereas references ends up being
two multiparts and four body parts; that's twice as many parts, and so
twice the opportunity to shoot myself in the foot.

Would it be too terrible to keep header-set for simple problems, and use
references for more complex ones?

Yes, that gives us two multipart things that perform similar functions.
But header-set solves in a simple way what looks to me to be a common,
simple problem, whereas references solves simple problems with much greater
difficulty.  Sorta like increment operators vs assignment with expressions
in C.

Steve Dorner, Qualcomm Inc.
    Sometimes it's easier to let your cockatoo eat your shoes
    than to hear him scream.

<Prev in Thread] Current Thread [Next in Thread>