- From: Miroslav Vodslon <miroslav.vodslon@gmx.de>
- Date: Thu, 1 Oct 1998 22:06:19 -0400 (EDT)
- 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 UTC