Re: Proposal for SIZE attribute

Brian Behlendorf wrote:
++ On Mon, 8 Jan 1996, Ian Burrell wrote:
++ > I was thinking recently that a SIZE attribute that indicated the
++ > physical size in bytes of an included object would be a useful
++ > addition to HTML.
++ ...
++ > Although the HTTP protocol
++ > gives the size in the header, this requires a network connection.  
++ Which doesn't really penalize you if it's done right.  Consider the news 
++ reader "trn" - it was designed to minimize the amount of wait-time by 
++ getting information from the news server in the background while you read 
++ posts or pick threads from a menu.  In the same way, the meta-information 
++ (size, content-type variants, etc) about a linked object can be obtained 
++ after the page has been loaded and rendered, but before a subsequent link 
++ is followed.  
++ As for using this to base decisions on inlining objects - the current 
++ netscape model of opening a bunch of parallel connections could handle 
++ the benefits you see this providing already.  With the addition of 
++ HTTP/1.1, a client could fetch the page, do a HEAD on each inlined 
++ object, and then fecth them in whatever order it prefers, all over the
++ same TCP connection.  It gets even better with HTTP-NG, when the server 
++ can send to the browser information the browser wasn't even aware it 
++ needed yet, like metainformation about inlined objects.

Ouch. trn is usually done over a local network, that doesn't really
hurt. But doing a request for each linke, even if it is only a HEAD one,
means a lot more traffic over the net. There are pages with hundreds of
links (all those people with their bookmarks files on line), I even have
a page with over 1000 links....

I agree that your suggestion would be the proper way to do it, as the
refering document does not have to store information about the refered
document. However, I am afraid the current state of technology is not
good enough to do it without paying a heavy price.


Received on Tuesday, 9 January 1996 21:43:30 UTC