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

Re: Serving insides of zipped mirrors?

From: Benoit Mahe <Benoit.Mahe@sophia.inria.fr>
Date: Fri, 02 Oct 1998 10:05:06 +0200
Message-Id: <199810020805.KAA23928@ender.inria.fr>
To: Miroslav Vodslon <miroslav.vodslon@gmx.de>
cc: Benoit Mahe <Benoit.Mahe@sophia.inria.fr>, www-jigsaw@w3.org

 First of all, this feature was not supposed to be really used by 
 users (I made it for fun), and the first version of Zip stuff
 was not really tested. This week I fixed many bugs, so you may have
 no problem with the next release (released this evening).

Miroslav Vodslon writes:

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

 You're zipidx is a org.w3c.jigasw.zip.ZipIndexer, isn't it?

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

 Relocate: for example if the target resource is accessed with
 http://www.foo.org/dir Jigsaw will send a relocate reply to the
 browser, and this time the request will access http://www.foo.org/dir/
 This just ad a '/' at the end of the URL when needed.

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

 Just to be sure you know it: *default* should be in the directory node.

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

 And they are ZipFileResource I guess.

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

 no, it's a computed attribute.
> 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? 

 No :(

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

 Automatic things should be done by indexers, not manually. May be 
 this feature is not described enough in the documentation.
 (Ceci dit, toutes les critiques sont les bienvenues ;-)

> I am still using Jigsaw 2.0beta2 with jdk1.1.6 under Windows NT.
> What am I doing wrong? 

 probably nothing.

> I am sure the ZipIndexer does work in some
> combination of jdk+OS, but which?

 Of course, it works fine on Solaris with the zip tool, but as I said,
 many bugs have been fixed now.

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

 No, it's a good idea.

 Regards, Benoit.

- Benoît Mahé -------------------------------------------------------
                      World Wide Web Consortium (W3C)
                    Architecture domain - Jigsaw Team           

  http://www.w3.org/People/Mahe - bmahe@w3.org - + 
Received on Friday, 2 October 1998 04:05:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:33 UTC