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

Re: Clarification on the indexer

From: Jesse W. Asher <jasher@gate.net>
Date: Tue, 03 Sep 1996 19:09:47 -0400
Message-ID: <322CBABB.4FDE@gate.net>
To: Anselm Baird-Smith <abaird@w3.org>
CC: "Bruce Nelson (bnelson)" <bnelson@www.css.filenet.com>, www-jigsaw@w3.org
Anselm Baird-Smith wrote:
> 
> Bruce Nelson writes:
>  > Anselm I think your are right insaying we would want to
>  > modify the indexer itself... our site is made up of a collection
>  > of materials that are....
>  > HTML Documents
>  > CGI (Lots of CGI)
>  > Documents from an imaging system (FAXes mainly)
>  > Dynamic Information coming from our engineering group
>  >
>  > and all of this information is either...
>  > Completely accessable
>  > filtered
>  > or not available
>  > according to the users security privledge and
>  > the objects access privledge
>  >
>  > if the information is not available
>  > I dont want the user to know its there
>  > ..our goal here was to have a site that would not say no,
>  > it would onlt make available the items that are accessable
>  > to the user.
>  >
>  > All of these objects are registered within a
>  > Sybase RDBMS along with the users and all of the security
>  > info needed to do this. our current project is PERL based
>  > but afer reading your initial papers on Jigsaw and working
>  > with the alpha we could see that we could intigrate many of our back-end
>  > cgi applications into the httpd.
>  >
>  > This is where the indexer came in as an issue. I think if we could index
>  > on the fly from our RDBMS instead of the default method according to the
>  > users access, we could bypass the need for cgi (or resource) controlled
>  > indexes and document serving.
> 
> Are you familiar with the way Jigsaw's indexer work ? WHat happens is
> the following: when a directory resource is queried for an URL it
> doesn't know about, it checks to see if an appropriate file exsist. If
> so, it hands it out to the resource indexer, that will return a
> suitable resource for that file (depending on extensions, if this is a
> file, or directory templates if it is a directory).
> 
> One thing I could do (let me know if this would help you), is the
> following: make the ResourceIndexer an interface, and make the current
> resource indexer a SampleResourceIndexer, implementing that
> interface. I would then add a new property to Jigsaw in order to know
> what indexer class it should use as an indexer.
> 
> If this makes sense (BTW to anyone) then the ResourceIndexer interface
> would probably look like:
> 
> public interface ResourceIndexer {
>      public Resource createDirectoryResource(File directory
>                                              , String name
>                                              , Hashtable defs);
> 
>      public Resource createFileResource(File file
>                                         , String name
>                                         , Hashtable defs);
> 
> }
> 
> The File parameter is the "object" to be indexed (it has to be refered
> to by something, in this case a File instance).
> The name is the identifier for the resource to be created (can be
> different from the file's name)
> The defs hashtable is a set of default attribute values for the
> resource to be created.
> 
> If this would be of any use to anyone let me know. Note that you could
> implement such an interface, and "chain" indexer together. Say you
> implement the FancyResourceIndexer, if it doesn't know how to create a
> resource, it could forward the call to a "default"
> SampleResourceIndexer instance.

How might this fit into accessing something like CORBA and an ORB? 
Would this be beneficial in that regard??
 
> I think I could find the time to make that change, but before going
> further, I want to make sure it will be usefull to anyone. So let me
> know.
> 
> Anselm.

-- 
Jesse W. Asher
Web Runner, Perl Apostle, Java Enthusiast, and WorldOS Believer
Why do they always increase airport security _after_ a bombing???
Received on Thursday, 5 September 1996 12:34:06 GMT

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