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

*some* questions

From: Anselm Baird-Smith <abaird@w3.org>
Date: Thu, 5 Sep 1996 17:04:53 +0500
Message-Id: <9609052104.AA11545@www18.w3.org>
To: Viktor <viktor@irisz.hu>
Cc: "'www-jigsaw@w3.org'" <www-jigsaw@w3.org>
viktor@irisz.hu writes:
 > I started to play with Jigsaw about two weeks ago, and started writing =
 > some resources (like a HTMLResource, which gets the title into the =
 > title-atrribute, a FolderResource, which creates frames with content and =
 > page, and uses the title attribute, if it's exist, etc...), or hacking =
 > the original (this I don't do so much, because on my platform there =
 > isn't a port of CVS, and what what will I do when the next release =
 > comes?)

Wow ! sounds cool. Parsing the HTML to get meta infos is something I
am defintely interested in putting in.

 > I spended some night discovering the source, and most of my questions =
 > answered, but there is still some on my list. Here they are:
 > 
 > - There is a date problem in DirectoryResource. I've made some =
 > debugging, and found that there is 2 hours differency among the 3 dates =
 > it uses (ims, list_stamp, lastModified), and it's probably a problem =
 > with GMT and local time (I'm in +01 zone, and there is DST). I didn't go =
 > further, just commented out this part in my FolderResource for now. Do =
 > you know something about?

I suspect they were some problems with the FileResource and how it
handled dates, I am not sure it was removed in the current release. I
am interested in any infos on the DirectoryResource since that hasn't
change much. Here are some hints:

ims:        is the request if-modified-since header value.
list_stamp: is the date at which the directory listing was last
            computed.
getLastModified: returns the date at which that resource was last
                 modified

So the following test in DirectoryResource should read as:

        ... getDirectoryListing(...) {
           // Have I already computed a directory listing ?
	if ((listing == null) 
           // If so, did the physicall directory changed since then
	    || (getDirectory().lastModified() > listing_stamp)
           // I have a listing, but did the resource change since then ?
	    || (getLastModified() > listing_stamp)) {
        ... 
    }

 > - A platform-specific problem: NT has a case-storing, but =
 > case-insesitive lookup file-system. This leads to the following =
 > situation: you have a file /foo, and you make lookup for /FOO, /Foo and =
 > /foo, then you will have 3 resources in that container, which isn't very =
 > healthy. Possible solutions:
 > 
 > 	- change the indexer to be case in-sensitive,
 > 	- change file.Exist to be case-sensitive,
 > 	- live with this.
 > 
 > A specific case is when you have FOO.HTML, which isn't indexed at all.
 > What do you think about?

This has been fixed in the next release through the following mean: if
the w3c.jigsaw.check-sensitivity property is set to true, then before
trying to index a file, Jigsaw will check its case sensitivity by
listing the directory first (which produces case sensitive file
names), and checking that the file to index exists there with the
proper cases.

This cost a directory listing on mispelled URL (not a so great big
deal).

 > - What intention is behind not to index files which has no matching =
 > extensions? There is lot of files in my repository, like README, =
 > foo.gram, html.dtd and so on, which I can't even see like this. I'm sure =
 > I will change this, and index these files as 'UnknownFileResource', =
 > having text/plain content-type, so probably this is just not a question, =
 > but what's your opinion?

FOr the time being, you have to index them manually. The next (public)
release - this will not be in the member release of next week - will
have towo ways of solving that problem:

a) You will be able to use register a *default* extension, that will
   be used to index files with no extensions.
b) You wil be able to write your own resource indexer to deal with 
   whatever you want (see previous mail)

 > - This is more a Java question: could I implement something like dynamic =
 > class unload and load, not having to stop/start the server after =
 > recompiling  a resource?

Yep, this is a java question. I beleive that if Jigsaw was to use
class loaders when loading classes, something would be possible. For
the time being, however, this is not possible (and not planned for a
futur release yet).

 > - I'm not sure if I should care about being a method synchronized, and =
 > if yes, when? Is it possible that while I'm generating the Reply to a =
 > Request, some other thread makes a confusion?

YES ! You shouild defintely make sure your methods are properly
synchronized, however, you will notie that all the basics resource
makes best effort to *not* be synchronized, since this is likely to
become bottlenecks. This is done only with great care (and largely
because resources don't store per-request state).

 > - I found something like small bug in LookupState.parseURI:
 > 
 > 	is_directory =3D (uri.charAt(urilen-1) =3D=3D '/') ;
 > 
 > Like this an URI like /foo/bar/?listing isn't a directory, so it wasn't =
 > looked up. I wrote a new ParseURI.

Can you give me the fix (for inclusion in next release ?)

 > - Some problem will be solved by the next release, like store the =
 > resources in simple ascii files. This would be a great help, because I'm =
 > not the thoughtful kind of programer, so often would change the =
 > attribute-list, and have to delete all .jigidx files, which makes =
 > impossible to store config-info for now (like index-file for a specific =
 > directory). But the next release will be in october, and I can't wait, =
 > so probably I will make an OtherSimpleResourceStore, and then I could =
 > run perl-scripts on the ascii files, when neccesery... I know ascii-file =
 > lookup isn't so efficient, but it's not yet a question.. and it could be =
 > a property of the server ("configurable" mode and "efficient" mode)

My take on this one is the following: I want to keep the "efficient"
way jigsaw uses to access index files, so rather then swiotching them
to ASCII, I would rather provide converters to/from ASCII.

You can already use w3c.jigsaw.resources.SimpleResourceStore to get to
the content of an index file, we just lack the other way round ;-)

 > Thanks for answering this (if you do... :).

Thanks for the feedback !

 > viktor@irisz.hu
 > 
 > p.s.: does anyone knows a port of CVS for NT? It would be enough a local =
 > version for now... I've looked around, but didn't find.

http://www.cyclic.com:80/cyclic-pages/getting.html

Anselm.
Received on Thursday, 5 September 1996 17:05:05 GMT

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