> May I propose the content file
> foo.htmld/.archivelist
most 8+3 name converters would drop the leading period
and insert it before the "ist"
> as a default name for CONTAINED files which should be
> presumed as a single unit for single transfer when
> an HTTP request is made for foo.htmld.tgz
>
> In this case, if foo.htmld/.archivelist exists, at a
> minimum, it will contain a single line with the name
> "index.html" Other files which are part of the
> "package" may also be specified.
Dan_Grillo@NeXT.COM responded..
> I'm not sure I understand. What's wrong with readdir(foo.htmld)
> as the way for the server to figure out what's in
> foo.htmld.some-archive-format?
For an EDITOR, that's ideal. For a daemon server, administrative
files that are peculiar to a given html editor may or may not be
appropriate for inclusion.
The documents and inclusions SHOULD stand on their own, as soon
as they leave the originating system. Yet, for an eText or comp-
arable distributed editing system, it may be desirable to retain
i.e. an access record apart from the actual documents, which does
NOT apply once the htmld leaves its resident system - that is, it
applies to the original but NOT to copies. There are likely to be
other items as time and development goes on, that pertain to the
original, but should not pertain to copies.
The server may incorporate the archiver code, or more likely,
invoke an archiver and pipe the output to the client, i.e....
popen( "/usr/bin/gnutar -cvzf - -T foo.htmld/.archivelist", "r" )
while the current versions of many common archivers in Opener.app
do NOT include a pipe option, the use of pgp (with its default
gzip) is something that is already forecast in NetScape and
Mosaic. PGP, of course has a pipe option (stdin-to-stdout) but
no direct collection-of-files. It won't surprise me a bit if
an upcoming version of gnutar adds a pipe-through PGP option
to go with the -z and -Z (gzip/compress) existing options.
Bruce