- From: Brian Behlendorf <brian@wired.com>
- Date: Mon, 10 Oct 1994 13:43:48 -0700 (PDT)
- To: hallam@axal04.cern.ch
- Cc: http-wg@cuckoo.hpl.hp.com
On Sat, 8 Oct 1994 hallam@axal04.cern.ch wrote: > Problem: > > When a document is composite (text & images) it is not nice to have to wait > for the whole document to load before display, but until the size of the images > is known this is tricky. > > Non-Solutions: > > 1) Opening up multiple TCP/IP sessions. This is a kludge. Very true. But it is kinda breathtaking and effective from the *client* end. > Solutions: > > 1) HTML+ allows the size of an image to be given in the text. We could imagine > some sort of "intall" utility to set up such info. This is exactly one solution being given by the same maker of this browser in their "extensions to HTML" document. But I don't like this too much, as I think it crosses the HTML structure-presentation boundary too far and isn't trustable (the HTML author or install procedure could be wrong, the image size could change over time, etc.) > 2) Using MGET we could imagine sending a resume of the images (size etc) before > starting the download. This could be sent in the message header > "image/gif; width=200; height=300; colours=256". Again this would > require some sort of install perhaps - or the server could > be intelligent and "know" about gifs, jpegs etc. > > This is where I think that MGET is not quite enough, we would also need an > MHEAD. I like this idea much more. I think the server could be configured to recognize image files and return coordinates like width, height, and color pretty easily - and it could cache that information for popular images. Brian
Received on Monday, 10 October 1994 22:07:53 UTC