[Sorry... I took a thread from the www-speed list and cross-posted
it to www-talk. I gues I didn't give enough background while I
was at it.]
Yes... a compound document architecture would do the world a lot
of good. But it's complex and messy. In the mean time, doing
multiple HTTP transactions over one TCP connection is a cheap
hack with big potential win.
>A nicer method would be to allow multiple GETs within a request.
>(or have I missed something) - so
> 1. get page
> 2. figure out which components need to be fetched. (modulo cached objs)
> 3. issue one request for all these objects
> 4. Receive one multipart mesg.
Just try looking at this another way:
1. Client opens connection to Server
2. Client sends request for page, with Pragma: keep-connection
3. Server sends HTML, but doensn't close the connection
4. Client examines HTML, finds a number of IMG SRC=...
5. Client sends a request to get each IMG over the same
connection
6. Server responds to each request as usual, except without
closing the connection
7. Client closes the connection.
Rather than multiple GETs in a request, we try multiple requests
in one TCP session. Hmmm... a lot of headers get repeated.
Perhaps this is what simon was saying about Accept: headers.
>So - any chance of this becoming useful?
Looks like it, as soon as somebody codes it up!
>> >each image by it's image number (e.g. <IMG SRC="icons.gif#3> would mean
>> >the third image in icons.gif).
>
>Eeek - where would this info be stored?
>GIF does not support named sections.
>Who would be doing the extraction - the server?
No, the client. But I agree that GIF doesn't have any "packaging"
info. Hence the rectangle hack. It's kinda like the way
Windows toolbar icons are done...
>Time to extract info from large gif would be small compared to
>multiple GETs. However, it is (IMHO) a worse solution than multiple
>distinct messages.
Ah... but consider a collection of 1000 chemistry documents that
have little alpha's and beta's all over them. A client downloads
chemistry-font.xbm once, and caches it for the whole session.
>> <IMG SRC="chemistry-font.gif#100,0,15,6">
>> Perhaps it's wise to use named, rather than positional, parameters, so
>> that somebody could pass font metric data too:
>> <IMG SRC="chemistry-font.gif#x=100;y=0;w=15;h=6;baseline=22;kern=0.6">
>
>WHAT ARE YOU THINKING?
>Ignoring for the moment the fact that no fonts are distributed as gifs,
>and that gifs are stupid way of distributing fonts, _what_ would this do?
Ok... so use xbm, or any other bitmap format. I don't care. The point
is that you can GET one image with a whole bunch of glyphs in it.
>Cause subsequent text to be rendered in this font (if possible?)
>Cause the font to be displayed on the screen? Install the font on
>your system???
No, no, no. It's used just like IMG SRC=... is used, for example,
by the LaTeX2HTML translation tools -- to incorporate little images
into the flow of text as a hack for characters that are not part
of HTML.
Dan