Re: Clarification on the indexer

Dave Makower writes:
 > YES!!! This would fit very nicely into a project we're working on, where we
 > would like to use the indexer to create "virtual directories" of
 > information that might not exist on the server at all.  Instead, there are
 > repository files (like .jigidx files) containing metadata, which is used to
 > obtain/synthesize/present the information on the fly when it is accessed.
 > By using a different indexer implementation, we could better integrate the
 > creation of these metadata repositories into the Jigsaw architecture.
 > 
 > What if, instead of CreateFileResource(), there were something more
 > general, like CreateHTTPResource() or CreateContainerResource(), or
 > something of that ilk?

You are right, the name should be less file-system dependant. Now I am
wondering if at all the indexer should have two methods (why is it up
to the caller to decide wether it is going to be a container or not
?). In the case of the DirectoryResource for example, it could call:

indexer.createResource(File file, ...);

and the indexer would do the appropriate checking (if its a directory
return a DirectoryResource, otherwise, ...).

Does this fits with everyone needs ? Do you want the disctiontion to
be explicit (createContainer/createResource) ?

 > Our "virtual directories" are not instances of DirectoryResource, nor are
 > our leaf resources instances of FileResource.  Instead, we are using more
 > abstract definitions specific to our architecture.  Our
 > VirtualContainerResource and LeafResource classes are, in fact, descended
 > from FilteredResource.  The reason for this is that DirectoryResource is
 > currently written in such a way that it must contain files/directories, and
 > our "virtual containers" contain more abstract entities.

Correct, that's the right way to go. I had to cope with the filesystem
resources first, but of course the ultimate goal is to populate a
server with less file-system centric resources...

Anselm.