Re: X Mosaic, FTP and PASV

Dave_Raggett <dsr@hplb.hpl.hp.com>

Mail folder: WWW Talk Oct 93-present
Next message: Dave_Raggett: "Re: a compromise on tables, etc."
Previous message: Dave_Raggett: "Re: X Mosaic, FTP and PASV"
In-reply-to: Frederick G.M. Roeber: "Re: X Mosaic, FTP and PASV"
Reply: Frederick G.M. Roeber: "Re: X Mosaic, FTP and PASV"

From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-id: <9312031812.AA27780@manuel.hpl.hp.com>
Subject: Re: X Mosaic, FTP and PASV
To: roeber@vxcrna.cern.ch
Date: Fri, 3 Dec 93 18:12:52 GMT
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

> 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.

In the HTML+ spec I introduced a SIZE attribute for anchors with
this in mind. People persuaded me to take it out, but maybe we
should put it back again :-)

> A browser could implement a selection for http-served documents
> which invokes a HEAD to find out this kind of information.  If
> this info included the time changed, it could be compared against
> the global history.

Yup. I see two scenarios:

  (A)   Browser builds directory listing for FTP host/path.
        The size is stuck into each <A> element for use when
        the user clicks on a file

  (B)   HTTP server builds directory listing on behalf of client
        The size is stuck into each <A> element for use when
        the user clicks on a file

In each case the information is fresh and so valuable for displaying
a progress gauge.

Thanks for bringing this up - I will write it up in the next version
of the HTML+ spec.

Cheers,

Dave Raggett