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

A general problem that I see in the proposals until now is that we have
no guarantee that the images are in fact on the same server as the main
document. Often this is _not_ the case and then it doesn't help to keep
the connection open nor is it easy for the server to get the size of
the image.

I think a general solution must be based on at least two connections.
First the main document gets retrived. If the client is text-based then
fine - no more connections are made. If not then the client can sort
the requests for inline images and make simultaneously (multi-threaded)
connenctions to the servers involved. These can then be multipart, MGET
or whatever solution we come up with.

This might not seem very elegant but I think it is necessary in order
to keep the flexibility and backward compatibility which in my opinion
is required.

Another solution could be that the client has a special header-line saying:

	keep the connection open - I will tell yon when to close

but then I think it's another protocol than the HTTP we are heading for.


-- cheers --

Henrik Frystyk 


> The following assumes that the client gets the html document and
> then sends the server a list of images to send next, reusing the
> same connection.
> 
> I like the idea of being able to get the image sizes in advance of
> the data, but would also like to be able to interleave the image
> data streams. This way users see all of the images start to appear
> concurrently, rather than one by one.
> 
> One simple idea is to use the segmented encoding approach and include
> the stream number with the segment length. The initial info on image
> size/type would specify the stream number for each image.
> 
> If this sounds too difficult, then at least the server could sort
> the images by size and send the small ones first.

Received on Wednesday, 12 October 1994 18:40:07 UTC