Re: Two new drafts: Multipart/Interleaved and Application/BatchBeep

> I only glanced at this, so maybe I misunderstood it.  However...
> given that the components of a multipart/interleaved aren't likely to be
> usable by a traditional MIME reader anyway, I see little point in
> using the MIME multipart syntax to distinguish one chunk from another.
> and I don't really see a good way to build this in such a way that
> existing MIME readers are likely to deal with it well.

I have a much more fundamental issue with this idea. I see very little utility
in this mechanism because it presumes that a client can predict when the server
will need certain content. I doubt very much clients will in general be able to
do this.

Perhaps this would work in the extremely simple case of an XML document with a
few embedded GIFs (although in such a case I'd simply embed the GIFs in the XML
text itself -- there are techniques for doing this). But anything else is going
to be a problem. For example, consider the case where you have a couple of GIFs
that are repeated dozens or hundreds of times throughout the document. (This is
a very common thing to do.) Now the client either has to assume that the server
will cache the image or it has to repeat it every time it is used. The former
may not work and the latter could easily increase the amount of data
transferred by several orders of magnitude.

Or consider the case where a more complex document structure with multiple XML
parts. Cases will arise where the client has no clear idea what order the
server is going to operate in.

In fact you don't even know level of granularity is needed even in the simple
cases. Even if you make this something the print server tells the client, I'm
not even sure how it would describe its constraints.

As I mentioned at the WG meeting in Minneapolis, I believe the correct solution
to this problem is for the server to ask for stuff when it needs it. The
obvious way to do this would be with two IPP connections, but this runs into
problems with firewalls. A better approach would be to use BEEP's multiple
session capability -- the client could send the control document over and the
server could request things from the client on a different channel. The result
is a single connection, just in time data delivery, and no need for the client
to have to try and predict when the server will need something. The
disadvantage is that it's a new protocol, but frankly, if this problem is worth
solving we should not be afraid of a new protocol to solve it. (I also question
whether or not more code would actually be needed -- predicting when a printer
will need something strikes me as quite possible a lot more code.)

> I would suggest a new application/multiplexed content-type which would
> be divided up into chunks, each chunk representing the next consecutive
> element of some stream.  Each stream could be a MIME body part, with
> the normal header and content, but each stream could also be fragmented
> as necessary.  Ideally, the semantics would be similar to multipart
> related, and it would be possible to transform an application/multiplexed
> content into an equivalent multipart/related content - just that in
> the first case the various components would be divided up into chunks
> and multiplexed into a single body part (as far as MIME was concerned)
> and in the second case the components would each appear as a separate
> MIME body part within an enclosing multipart/related.

These are all just syntactic details. I think the problems here are
more fundamental than that.

				Ned

Received on Monday, 16 April 2001 20:14:14 UTC