> This is the right way to do it, I believe. We've kicked this idea around
>before (see background messages included below), and it's clear that using
>multipart messages is a big win in other ways, too. For instance, one
could
>use multipart messages to deliver pages containing sections which would be
>displayed only if certain conditions were met. The rules specifying how
and
>when the various sections should be expanded/collapsed would be delivered
>along with the other parts, perhaps as the first part of the multipart.
Note
>that this technique is also useful for delivering encrypted information,
and
>for including the DTD along with a document instance (when we abandon HTML
for
>arbitrary DTD's :-)
> In fact, I have been thinking about how one would go about defining
standard
>ways of putting together such multipart packages. To use the techniques
>mentioned above, we would need to define a control scripting language for
>describing the relationships between the different message parts and for
>orchestrating their interaction. In my thinking, this control language
shares
>some characteristics of the 'Universal network graphics language' which Tim
>brought up on this list last week. Although I think 'Universal network
>graphics
>language' is a misnomer for the kind of thing we wrote about - graphical
>objects
>are just one of the object types we're all interested in squirting around
the
>net.
I think that we have two interlocking needs here. One is the ability to
send multimedia non-interactive objects, which MIME was developed to handle.
What I got from Tim's message (which may not be what he meant :( ) was the
ability to dynamically and interactively send multimedia around, so that you
could have events like SIGWEB #4002, "The First On-Line SIGWEB!", or more
prosaically, videoconference your company's East and West Coast engineering
staffs in a brainstorming meeting with shared whiteboards (rather than
erase, just spawn an additional whiteboard...). Some kind of scripting
language seems appropriate, as defining the primitives needed for such a
language is probably at least an order of magnitude easier than anticipating
every potential use of these capabilities. Although we may not need to
bound by the same constraints as MIME (most notably, handling mailers with
broken line-length and character-set handlers), the MIME nested multipart
structure looks like a big win to me also. Any language designers care to
respond?
======================================================================
Mark Fisher Thomson Consumer Electronics
[email protected] Indianapolis, IN
"Just as you should not underestimate the bandwidth of a station wagon
traveling 65 mph filled with 8mm tapes, you should not overestimate
the bandwidth of FTP by mail."