W3C home > Mailing lists > Public > www-jigsaw@w3.org > September to October 1998

Re: Serving insides of zipped mirrors?

From: Miroslav Vodslon <miroslav.vodslon@gmx.de>
Date: Thu, 1 Oct 1998 22:06:19 -0400 (EDT)
Message-ID: <3614354A.1B74FA03@gmx.de>
To: Benoit Mahe <Benoit.Mahe@sophia.inria.fr>
CC: www-jigsaw@w3.org
Hello again,

OK, now I am able to browse some zip-archives. Thank you Benoit for
responding so quickly!

I am all the more sorry to have some more negative experiences to
report.

- My zip-indexer creates resources and frames for leaves only. No
  ZipDirectoryResource for a directory inside an archive other than
  the top-level one ever created automatically by the
  zip-indexer. (And I think the top-level ZipDirectoryResource is
  created by the default indexer's to satisfy its zip extension
  atributes, not by the zip-indexer.) I have tried archives created by
  WinZip and archives made by info-zip under Linux.

- Therefore, for each non-top-level directory inside a zip archive, I
  have to create a ZipDirectoryResource, add a ZipFrame then edit the
  newly added ZipFrame to check the 'Browsable' control and possibly
  also edit the style sheet link. Unfortunately, this is not
  acceptable for my purposes.

- Often, no directory resource can be created, even manually.  I am
  unable to be more precise. It looks like a random condition. E.g.,
  try to create manuallly resources for a zip structure like this,
  where some directories have only one child, and that is another
  directory:

 gmu/
 gmu/departments/
 gmu/departments/fld/
 gmu/departments/fld/classics/
 gmu/departments/fld/classics/blueret.gif
 gmu/departments/fld/classics/ovid.amor.html
 gmu/departments/fld/classics/ovid.amor1.html
...

- Sometimes, the default indexer fails to index even leaves which are
  direct children of the top-level directory in an archive. Looks
  random as well. The archives seems to have no children, but it does
  have some in reality...

I checked my zip-index (I'm calling it zipidx) and checked it
again. It has a *default* ZipDirectoryResource with indexer zipidx, is
extensible and has a ZipFrame of Content-type text/plain, with
Relocate (I don't know what that means) and Browsable on.  *default*'s
ZipFrame also has a Style sheet link, /style/directory.css. Everything
else is blank (I don't know what that means) or off. Index is blank
followed by <none>.

zipidx has some extensions as well: gif, htm, html, txt. They all have
ZipFrames.

The default indexer has a zip extension, which is a
ZipDirectoryResource with a Relocatable and Browsable ZipFrame with a
different identifier (do the identifiers of the Frames matter?).

I would like to add here a clear and concise extract from a
human-readable Jigsaw configuration file or script or state-dump to
illustrate these assertions, but unfortunately there is no such thing,
or is there? Developers, including website developers, I think,
usually like to automate repetitive tasks. Jigsaw seems to offer
nothing in-between two equally unwieldy administrative paradigms:
1. point and click, dull, repetitive and error prone, and 2. hard-core
Jigsaw hacking in Java, interesting but just as error prone. Also, it
strikes me as imprudent to rely entirely on binary databases for so
young a program. (Ceci n'est pas une critique, juste un regret... :-)

I am still using Jigsaw 2.0beta2 with jdk1.1.6 under Windows NT.

What am I doing wrong? I am sure the ZipIndexer does work in some
combination of jdk+OS, but which? Have you tried non-flat archive
structures? Is it an error to have a zip-extension in the default
indexer in addion to a zip-indexer?

Thanks in advance,

Miroslav.
Received on Friday, 2 October 1998 05:22:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:28 GMT