RK-> This is one of the few areas in which WebStep needs to
RK-> reach out to the server community: we can't define tags
RK-> or graphics formats, but we will need to have clients
RK-> and servers that can download entire directories, if
RK-> users want local copies of vended htmld. What's the right
RK-> answer:
RK-> * clients that "walk the tree" trying to download resources
RK-> * servers that package tgz and (clients already can handle it)
RK-> I think that vending htmlds definitely calls for packaging
RK-> the entire driectory tree: included directories can be slide
RK-> shows, etc.
On consideration, I'd say that vending an entire tree can be
overkill - especially when TEXT MODE browser clients access
an htmld/index.html. If contained htmld's are shipped at
the same time - a short index.html could bring a quite sizable
chunk to someone who may be using a telnet to ukansas.edu to
try out lynx, for example, leaving them with no choice but
download that same chunk, perhaps to a machine with NO browser.
Not everyone accessing an htmld can be presumed to have a T1
connection just an ether hop away from their PA-RISC or Sparc.
On the other hand, if a Smart client requests an htmld.tgz when
an htmld is pointed to in the referencing URL, it can be presumed
that the entire htmld and contents may be presumed usable, and
for clients that allow a save of the current page without a re-
fetch, (or, i.e. cache in /tmp - with the knowledge and desire
of the user) having at least the CURRENT level can be quite
handy.
If an htmld.tgz is requested of a server that is unable to
automatically archive for transfer, it will reject the altered
URL, and the client can request the plain htmld, receiving only
the index.rtf on the first successful transfer. If an htmld
is requested of a Smart server, and it actually has the content
as an htmld.<archive extension> it should unarchive the
index.html and return it alone.
I still don't think a meg or two of sound or graphics buried
3 htmld's deep should be returned when the top level htmld is
requested. That kind of defeats the purpose of links, thumbnails
and icons with a WARNING about the size of their target.
On the other hand, if ONLY the actual content of the current
level htmld is returned, the transfer savings can be considerable
even for negotiation for embedded grahics transfers for IMG SRC
or IMAP's.
Should there perhaps be a standard content file that can be
passed to a server using gnutar -cz -T to pass an htmld.tgz
Bruce