We've implemented metadata generation within the webDAV layer on our Slide-based SAM project (http://www.scidac.org/SAM/) - using a web gui, root users can specify a combination of XSLT, BFD (a language for pulling stuff out of binary files and tagging it), and/or a web service to extract metadata from the resource and populate live (read-only) DAV props.
We put this up in Webdav to avoid the changes in the Slide core going from 1 to 2, but the core is the the better solution - we've been waiting for events and the JCR spec before worrying about moving things. So - +1 for events from a non-commiter and encouragement to synch with the JCR spec as it moves forward (JCR has vetoable and nonvetable events and filters/selectors, but I don't think there's a collection concept yet - JCR should hopefully go out for public review soon). Jim ----- Original Message ----- From: "Daniel Florey" <[EMAIL PROTECTED]> To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, February 03, 2004 11:47 AM Subject: Re: proposal: integrate indexing - search Hi Martin, Am Dienstag, 3. Februar 2004 17:07 schrieb Wallmer, Martin: > Hi Daniel, > > > -----Original Message----- > > From: Daniel Florey [mailto:[EMAIL PROTECTED] > > Sent: Dienstag, 3. Februar 2004 16:27 > > To: Slide Developers Mailing List > > Subject: Re: proposal: integrate indexing - search > > > > > > Hi, > > great work. After reading it several times I understand most of it :-) > > As I'm working on events at the moment I think they could be > > used to trigger > > indexing for lucene based search. > > They provide synchronous event collections (before commit and > > vetoable) as > > well as asynchronous event collections (fired after commit). > > The collection can be filtered, so that only the desired > > changes are indexed > > that could be a way to trigger the indexer. My current thoughts are to > trigger the indexer within the parent store > (org.apache.slide.store.AbstractStore.java). Here we have a good chance to > let the indexer take part in two phase commit. It's up to the indexer > implementation, if two phase commit is used, or asynchronous processing is > done. I'm just on AbstractStore. I hope that that some day in the future someone will vote for my event stuff so that we can see if it fits to the needs of indexing. It should be possible to implements indexers that can take part in a transaction so that search queries reflect that content that was changed in the transaction (as it possible with rdbms). But this should be achieved by the use of events as well. The advantage of events is that different aspects of slide could be configured in the same way and can be coupled loosely without bloating up the core classes. Another advantage is that events could (in the future) be distributed in a clustered environment so that the search index could be clustered as well (just brainstorming). But I think we should take two phase commit into account, so I'll think about this. > > > (e.g. create and remove of the same resource within a single > > transaction can > > be ignored). > > that would be a benefit. > > > To enable content type specific indexing it might be a good > > way to register > > some content type specific event listeners that extract the > > metadata from the > > resource and generates appropriate properties before storing > > the revision > > descriptors so the underlying store. > > Good point! We should should spend some time thinking about an Indexer > framework. I think a benefit of the separation of metadata extraction and indexing would be that extracted metadata is not only stored in indexes but could be edited via webdav as well. > > Regards, > Martin > > Gr��e aus Hamburg, Daniel > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
