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

Re: Clarification on the indexer

From: Anselm Baird-Smith <abaird@w3.org>
Date: Fri, 6 Sep 1996 22:44:47 +0500
Message-Id: <9609070244.AA16260@www18.w3.org>
To: Dave Makower <davemak@pencom.com>
Cc: www-jigsaw@w3.org
Dave Makower writes:
 > Forgive me if I'm misunderstanding this -- the indexer is still one part of
 > Jigsaw that I haven't fully come to grips with.  However, in your suggested
 > revision for the ResourceIndexer, I think there are still dependencies on
 > physical filesystems.
 > For instance, the first parameter to localCreateResource() and
 > createResource() is a File object.  In the original version of
 > createResource, the first parameter is named directory.  It seems to me
 > that instead, we should pass in a ContainerResource.  In other words, we
 > are creating a new resource inside some ContainerResource, not necessarily
 > inside a directory.  Of course, in the default case, the ContainerResource
 > would be an instance of DirectoryResource, tied to a physical directory.
 > However, with this modification it would be possible to create "virtual
 > containers" that are not directories, yet mimic the hierarchical
 > containment structure that directories provide.

I know, this File parameter may seem funny. One way of getting rid of
it would be to use the extra arg (provided for that purpose). So we
would have:

createResource(String name, Object arg, Hashtable defs);

in the case of the SampleResourceIndexer, we would then have:

createLocalResource(String name, Object arg, Hashtable defs) {
    if ( ! (arg instanceof File) ) {
        // I only know how to do file indexing:
        return null;
     // Proceed normally.

[note that I have also shuffled the args order]

I am not sure about the ContainerResource stuff. Basically it's the
container that explicitly call the ResourceIndexer, so I don't
understand why you would want to have it as a parameter (did I miss
something ?)

 > Am I correct in understanding the following?
 > 1) localCreateResource() is meant to return a Resource only if this
 > particular class of ResourceIndexer will accept the supplied parameters,
 > and otherwise it returns null.


 > 2) createResource() is meant to return a Resource by any means necessary,
 > traveling up the list of ResourceIndexers until it finds one that will
 > return a non-null value, and only returning null if all else fails.

You would normally stick to the default implementation of
createResource. Note that createResource is defintely specified as
being allowed to return null itself; Otherwise, the order in which the
indexers are chianed together implicitly mandates which indexerwill
get a chance at indexing...

 > How might localCreateResource() determine whether to return null, or to go
 > ahead and create a resource?  Does it have to do with whether or not this
 > is the indexer registered to the specified container?  Or does it have to
 > do with the Object arg?  I imagine it could be either, but what would it be
 > in the default case?  Would the final arg be used at all in the default
 > case, or is it just for the sake of generality?

It was there for the sake of generality, and now as a replcamement for
the File, if this sounds ok to people here.

BTW: about containers. There is currently no  way to attach a specific
indexer to a ContainerResource (say a DirectoryResource) at that
point. I can see how  this could be done , but the above scheme would
be defined only server wide (although the same scheme might be used
"locally"). You might have a indexer attribute in your container
resource, that will allow you to point back to a specific indexer,
that you will use for that URL space...

Received on Friday, 6 September 1996 22:44:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:41:21 UTC