Tag change to speed up low bandwidth links; (why not done/comments)

Greetings,
I'm looking at HTTP1.1 HTTP/NG andam really interested in CATV style 100K
seat multicast and non multicast.
I keep looking for hooks in your spec for HTML so the following is totally
reliable. Very often a HTML author will reuse lots of components, graphics;
(typical JPG GIF), etc. Now Each uses its own GET.

I gather this will be 'fixed' this in http1.1. However, if the local machine
(or set top converter) could
absolutely KNOW the objects inside the HTML are the same as the last time,
it could use the
last sent instance, over any number of sessions, (not just one session). The
point being the
larger bandwidth eaters could stay really  local. for instance?

<img src="redball.gif"> could be <img src="redball.gif"
absobject=1215231341555671>

The local machine could scan its local registry, and if the object ID AND
number are the
same display the local copy. The author would change the absobject number,
(but not
nessessarily filename). Of course, the entire message should be marked to
refetch fresh,
(not from the proxy).

Seems to me the MIME elements SHOULD be able to do this with some wildcard
attribute,
but I have never seen a browser exhibit this behavior. Envision each time
you get the New
York Times, you get a graphic of the banner, edges, buttons that say
"forward", "back", etc.

Interestingly, if the html creator 'steals' a filename and keeps the number,
your local machine
could even display am item from a previous session from another source.

If this is possible now, why isn't it done, I wonder? If you think its
useful I could cobble
together server software and a plug-in to Netscape to show this work.

Important objects might be betther off not using the absobject tag, for
forgery issues beyond
the scope of this initial message.

(If someone else comes to mind regarding this, please feel more than free to
forward it
to them without further comment from yourself(s)).

Regards/ Thanks

Dan Kolis
dank@tanda.com
Tuttle and Associates

Received on Friday, 22 November 1996 03:23:53 UTC