Re: Deploying...

Kee Hinckley ([email protected])
Mon, 31 Oct 94 11:54:05 EST


----- Transcript of session follows -----
While talking to www0.cern.ch:
>>> MAIL From:<[email protected]>
<<< 554 buildaddr: no host
>>> QUIT
<<< 554 buildaddr: no host
554 <[email protected]>... Remote protocol error

----- Unsent message follows -----
Received: from utopia.utopia.com.utopia.com by wraith.utopia.com (4.0/SONY-4.0MX)
id AA27788; Fri, 28 Oct 94 13:41:12 EDT
Return-Path: <[email protected]>
Received: by utopia.utopia.com.utopia.com (4.1/ASI-1.0)
id AA06340; Fri, 28 Oct 94 13:45:03 EDT
Date: Fri, 28 Oct 94 13:45:03 EDT
From: [email protected] (Kee Hinckley)
Message-Id: <[email protected]>
To: [email protected]
Subject: Deploying new versions [Was: Versioning HTML at the server]

> By the way... does the idea of the server gratuitously packing up
> inline images with html files into a mime multipart/mixed body really
> look like a good idea to anybody? What about client-side image
> caching? What about per-image errors?
>
> Doesn't it make more sense to just allow multiple transactions over
> the same connection? For example:
>

Some more rambling.

That certainly makes sense to me. You might want to go further
than allowing parts to be returned out of order though, you
might want to allow them to be returned in packets out of
order (well, for each request the contents would be in order).
This would enable what Mozilla does (which gives the appearance
rof greater speed, and updates the little dohickeys on the screen
faster than the big images you may care less about) without
requiring multiple TCP connections. This also handles the case
of a multi-threaded server which is doing conversion on the fly,
body parts which are slow to convert simply appear less often
in the data stream. That said, I'm not certain it's worth the complexity.

There's another reason that Mozilla does it that way which goes
beyond just making a pretty display. It's finding out the image
sizes on the fly and sizing the text around them, which makes
the entire page usable sooner and can cut down considerably on the
redraws. That could be addressed by providing a protocol to get
the size information, or by requiring that the HTML doc contain
the size info (which I believe Mozilla's extensions do allow).
Of course none of that helps much for arbitrary wrap around images.

Speaking of inlines. Has anyone tried doing inline audio?
I have this vision of something like:
<audio src="foo.au" repeat>
to give nice ambience to a page.