> I misspoke on inlined images. There's nothing wrong with the IMG
> element. But I think we need a way to combine image/gif data and
> text/html data into one transaction. But that technique is not
> ready for standardization yet. That's what I meant.
I agree that rolling them into one transaction is desirable. I do not see that
this needs anything radically different, however.
One situation where this was brought forcibly home to me was a project
experimenting with electronic journals. One section of one paper can have 50 -
200 inline images. Why? because it is a materials science journal, and each
single occurence of a alpha or whatever is a separate, small image. (Currently
an XBM; soon to be a 64 greyscale GIF with a transparent colour, i hope).
I notice that much of the time the delay is in establishing a connection, ie
latency rather than transfer rate. So bringing the whole lot over as one chunk
would be a *lot* faster.
Now, the brower knows whether inline images are switched off or not. So it knows
that if a document has inline images, it is going to get them. All. One at a
time.
The problem is that the accept: types are being ignored, I think.
When a user switches off inline images, the browser should adjust its list of
accepted MIME types to not include any image types.
Browsers should accept (and be able to handle) MIME multipart messages.
Servers should take notice of the accept types in a request, and do something
sensible with them.
So what I propose is: (and no I don't remember the exact syntax - sorry)
Case 1: client has inline images ON and supports multipart messages, server is
multipart aware
GET blah.html ACCEPT (various image types, others) multipart/mixed
Server bundles up blah.html and all its inline images as a MIME multipart, ships
it all over the net in one go, client unpacks it and does the right things with
the bits.
Case 2: client has inline images OFF and supports multipart messages, server is
multipart aware
GET blah.html ACCEPT (no image types, others) multipart/mixed
Server sends blah.html as current situation
Case 3: client has inline images ON and supports multipart messages, server is
multipart dumb.
GET blah.html ACCEPT (various image types, others) multipart/mixed
Server sends blah.html as current situation, client realises it does not have
the inline images so it gets them, one by one, as curent situation.
Case 4: client has inline images ON and does not support multipart messages,
server is multipart aware
GET blah.html ACCEPT (various image types, others)
Server sees client does not accept multipart, just sends blah.html as current
situation.
The only drawback I see is that some processing is needed on the server side;
either pre-generation of a convenient list of inline images or parsing of the
html files before sending them when the incoming GET accepts multipart/mixed.
Perhaps this could be done incrementaly. The server looks for some file -
.blah.html, or something - and if it is not there, parses the html file to find
what images need to be bundled up. After it has sent the multipart it writes
.blah.html to save time next time.
So: what I have suggested would give a performance improvement, would require no
changes to existing or future html documents and would simply require browsers
to adjust their accept types appropriately and servers to take some notice of
them. I think it would fit the current HTTP spec or be a trivial and logical
extension of it conformant with current MIME practice. Code to implement client
side splitting of multipart messages is already available such as the mm stuff
from bellcore (would that be useable?). Existing browsers and existing servers
would not be affected.
If anyone sees something I have overlooked, I would be glad if they would point
it out.
Chris Lilley
+-----------------------------------------------------------------------------+
| Technical Author, ITTI Computer Graphics and Visualisation Training Project |
+-----------------------------------------------------------------------------+
| Computer Graphics Unit, | Internet: [email protected] |
| Manchester Computing Centre, | Janet: [email protected] |
| Oxford Road, | Voice: +44 61 275 6045 |
| Manchester, UK. M13 9PL | Fax: +44 61 275 6040 |
| <A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">click here</A> |
+-----------------------------------------------------------------------------+