shared wasabi implementation

[Joe Shaw]

Hey,

Mikkel Kamstrup Erlandsen wrote:
> I think I mentioned "getters and setters" for metadata somewhere in this 
> thread, but that's not entirely obvious from the context of the mail you 
> reply to :-) The methods I suggested was only for ingesting in the 
> index. Or are you saying that there should also be a way to set metadata 
> on the indexer and not only via the metadata api?

Maybe, yeah.  I wasn't thinking about the metadata spec when I wrote 
this; I'm still not convinced that we should have metadata getter/setter 
APIs as part of the spec if we're just focusing on the search side of 
things.

The possible API I was referring to would be so that additional 
properties can be set on an already-indexed document.  To give an 
example: Beagle adds Nautilus metadata to files by parsing the XML files 
while the file system is crawled.  It would be much cleaner (and 
extensible) to have a separate backend which itself crawled Nautilus 
metadata and added properties to already-indexed files in the database.

> The mailbox was mainly meant as an example, but let's stick to it 
> anyway. What I meant to say was that you can index the mailbox at any 
> time, but the is no need to keep a watch out for changes since the only 
> app that is ever going to change it is (say) Evolution. In a metadata 
> aware desktop Evolution would be emitting signals (or whatever) when the 
> mailbox changes (perhaps with hints as to what changed).

Sure, this is the ideal situation, but it means that you need to have 
internal crawling code and an external handler to deal with changes as 
they come in.  The bulk of the code (and the hard part, really) is 
usually the crawler.

Joe