Image-Hints: (was Re: Comments please on agenda for HTTP working group BOF)

Jeff Hostetler (jeff@spyglass.com)
Mon, 10 Oct 94 10:13:07 -0600 

> It should be noted that one company's solution to the problem of 
> time when loading html pages with lots of inlined images was to 
> 
> 1) grab the page 
> 2) note the images needed for download
> 3) open up separate TCP connections for *each* image
> 4) find out the width and height of each image as it's coming down the 
> pipe, laying out a box in which the image gets filled in as it arrives - 
> thus allowing the page to be layed out perfectly before all images are 
> received.
> 
> [...]
>
> Could we get that same effect with one connection?  Sure - the browser 
> must be (simulated if not OS_supported) multithreaded, so it can be 
> accepting data and rendering simultaneously, and when accessing inlined 
> images a HEAD command should be sent for each image whose response shows 
> how much screen acreage it'll take (which I *think* can be determined 
> in the first couple of bytes of any GIF or JPEG).

There are 2 problems being discussed here:
1) how to minimize the number of TCP connections.
2) how to help the client do the document layout
   before it has the images (or image sizes).

I'd like to work on these independently.

Problem 1 is pretty much obvious -- we need to work on it.

Problem 2 can be solved with or with out Problem 1.  I defintely
do not like the *wasting* of network resources as is described
above.  I would like to discuss one or both of the following:

a) extend HTML to include image size information for inline
   images.  [This is a real pain for those of us with a lot
   of content and/or those of us who hand-code the HTML.
   But with the increasing availability of HTML authoring
   tool, this issue is less important.]  [I realize that this
   suggestion does not necessarily belong within the domain
   of this mailing list, but it is a method of solving the
   problem and if adopted, we wouldn't need to do anything
   to HTTP....]

b) have the server provide ''Image Size Hints'' in the document 
   response header for all inlined images.  This does not require
   any content to change, but does require some extra work from
   the server (eg, scanning HTML to find the images referenced
   and looking up their sizes (when local)).

The nice thing about both of these is that if the information
is absent (either not in the HTML or not provided by the server),
then the client falls-back to the current method of document
presentation.

jeff