> Got another crazy idea. As I was watching my web logs, and the Mosaic p4
> status display, it occured to me that when there are lots of small <4k inlined
> images, it typically takes longer to establish the connection than transfer the
> file. Hence a new tag
> <imgpkg src="URL">
> which could be something like a tar file with all the inlined images in it.
> references on the page would be stay the same (i.e. <img src="URL.gif">)
A better solution for HTTP servers, is to adapt servers and browsers to
support the MIME multi-part message format, and supply the images along with
the document. Each part should supply its URL in the part header. This way
the browser will put each message part it receives into its cache, so that
when it comes to render the document, it looks up the URL of the image in its
cache and hey presto - the images are already there! I guess, that you may
want to include a header in the HTTP request so that the server knows the
client can cope with multi-part messages.
For other servers, we could embed small images in the document directly
provided that the majority of browsers can cope with the format (no format
negotiation possible this way). e.g.
<IMAGE>
<EMBED TYPE=GIF>
....
</EMBED>
A photo of the author.
</IMAGE>
A suitable character encoding is needed for the image data, either based on
MIME or perhaps the more compact ASCII base-85 encoding used in Adobe's PDF?
Comments please.
Dave Raggett