> Friday evening, I said:
>
> >> If we had a place for storing information related to a document,
> >> (do we? There's talk about a "Hyperdoc" type in HTAnchor.c, but
> >> it's never flushed out.), then the size (as a number) should be
> >> put there. Then all those browsers that currently give transfer
> >> status in bytes could give it as a percentage.
>
...
> Actually, I meant in the standard libwww C code.. I'm one of the
> folks who's firmly in the "information like this doesn't belong
> in the html anchor" camp myself.
>
> I was thinking that if the in-memory structures the browsers used
> for the document anchors had such spaces, then perhaps another
> selection (e.g., shift-m1 or m3) could get and display header
> information from protocols (like http) which support it. Things
> like ftp, where directory listings give it for free, would just
> stick it in.
Every object which has a URI has, in the libwww, an
HTParentAnchor object which contains the metainformation.
Currenty we are extending it with for example pointers to cache
items. It has the address, and known links for the object.
The size is not in there but should be.
The name of the HTAnchor module is kinda related to the
name of the A element in SGML but it has a lot more.
In fact the HTChildAnchor subclass is the thing which
exists for each <A>.
Tim