Akil wrote:

> I am a newbie at both WebDAV and Slide, though I have read most of the
> documentation as well as much of the API JavaDocs for Slide as well as some
> of the specification documents at webdav.org. I also looked through the
> archives of the user and dev lists. That should give you an idea of my level
> of knowledge.
> 
> I started a project a couple of weeks back to facilitate the use of the
> SourceWare Server as the content indexer with Slide in order to be able to
> provide full text search. Eventually I plan to implement a SourceWare Store.
> (SourceWare Server is a database with an integrated full text search engine
> supporting Batch and Incremental Indexing, Flexible Semantics, Field
> searches, ... with a Java based CORBA API i.e. no SQL.)
> I will be setting up a web page for this project in a week or so.
> 
> In the short term, I am trying to just do the content indexer piece in
> SourceWare. The Search piece will be Tomcat based, access the indexing
> SourceWare server directly and act as a client of Slide when retrieving
> documents.
> 
> There are a number of ways to implement a SourceWare based content indexer
> for Slide and the most appropriate way would be to
> implement the IndexStore interface and associated mechanisms.
> 
> Due to the urgency of the situation, I would like to take a short-cut for
> the first pass and implement it by adding a ContentInterceptor that has a
> poststore and a postremoval method. I have a few questions regarding this
> approach.
> 
>                1.   I saw some information regarding the addition of the
> post-removal method to the ContentInterceptor class (as well as associated
> mechanisms) in the dev list archive. How come the code is not in
> last-night's build? Is it going through a code review process?  Or have I
> missed something?


I've sent a patch to add a postRemoveContent() method to the
ContentInterceptors but this one has to be tested by commiters before to 
be included into cvs tree (it modifies some critical classes like
StoreImpl).


>               2. Has the issue regarding access to the Namespace
> Configuration in the ContentInterceptor class been resolved?


In the patch too, but I think it could be done smarter than it is.


>              3. Although, this is not required in the short term,
> eventually, the Search Engine would also need the Access Control List
> information per node to be able to tune the search for a particular user.
> Post search verification is not feasible when the visible portion of the
> namespace is sparse for a given user.
> 
>                  For this purpose, I would need to get the list of
> permissions that are explicitly set for a new node. Moreover, I would need
> to intercept any changes in the permissions for an existing node. Any ideas
> on this? The way I understood it, the content interceptor is only invoked
> when the node being added/retrieved/removed has non-zero length content. How
> do I intercept security permission creations/modifications/deletions.


To retrieve/set permissions on a given node, you can use the security
helper, but I don't know how you could simply intercept permissions
changes (patching SecurityImpl ?).


>             4. Any major flaw in my approach to either the short term / long
> term projects?


Personnaly, I think that indexing is a heavy task and performing it on
each store actions through Interceptors could be very heavy.
Scheduling indexing or reindexing for the nigth could be a good idea if
your system is not used worldwide and does not neeed absolutly up to
date indexes.

Have you seen what is going on with slide and DASL ?
If not have a look at org.apache.slide.search package

JP


> If messages of this sort are more appropriate on the dev group, please tell
> me so that I can do the right thing next time
> Thanks


> Akil
> [EMAIL PROTECTED]
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 
> 




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to