W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: Propsal: MHEAD for Fast inline image formatting Was: Multiple connections

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
Message-Id: <Pine.3.89.9410101349.G7549-0100000@get.wired.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* 

> 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

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 

Received on Monday, 10 October 1994 22:07:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:12 UTC