simple search api (was Re: mimetype standardisation by testsets)

[Jamie McCracken]

Adam Lofts wrote:
> Hi,
> 
> On 28/11/06, *Magnus Bergman* <magnus.bergman at observer.net 
> <mailto:magnus.bergman at observer.net>> wrote:
> 
>     Is it only realistic
>     that users would want (or should be able) to do such simple searches? I
>     think it's realistic to imagine that there can be different search
>     engines which are good at different things. Perhaps one is good at
>     finding media files by their tags. One that is good at finding relevant
>     information from fuzzy terms.
> 
> 
> The multiple search engine problem seems to be the perfect use case for 
> dbus naming. Each search engine registers a well known unique name e.g. 
> "org.novel.Beagle.simple"  and tries to own "org.freedesktop.search.simple".
> 
> Thus if I want to be picky about who to query I ask for the engine 
> specific name, and if I don't care (surely the common case) I ask for 
> the well known name. Wrapping a library around this would be fine, but 
> the main point of the spec needs to be defining this interface 
> ("search.simple") and getting everyone to implement it.
> 
> On 28/11/06, *Magnus Bergman* <magnus.bergman at observer.net 
> <mailto:magnus.bergman at observer.net>> wrote:
> 
>     At least I see it there has to be some kind of daemon if there is a
>     dbus interface. 
> 
> 
> Use dbus activation.
> 
> 

thats what I have been saying to mikkel (in private). We really dont 
need a lib/daemon

Also I agree with most of what Joe Shaw has said on this thread

We should punt query language and metadata names to a later spec and 
concentrate on getting a very simple implementation going first.

As for live queries, I dont like dynamic interfaces and in tracker we 
will simply take a live_query_id as a param and use dbus signal 
filtering to listen for changes to that specific ID

I would suggest having a PrepareQuery method which returns a unique 
integer for the query then you can use that to :

1) Execute the query
2) Get the hit count
3) listen (using dbus match rules) for specific changes (hit added/removed)

Its simple and avoids bad practices like dynamically chanigning 
interfaces (and is no less efficient)

Heres my suggested spec for Wasabi:

ServiceTypes is an array of service names like "Files", "Emails" etc 
need to define full list)


method PrepareQuery (ServiceTypes as, query s) return ID i

method ExecuteQuery (int ID, offset i, limit i) return as (array of uri's)

method QueryHitCount (int ID) return i


signal QueryHitAdd (ID i, uri s)
signal QueryHitRemove (ID i, uri s)

The above is easy to implement and should cover the simple ground

For nautilus also needed is extra methods for searching files by mime 
types and/or location - these can be separate methods as tracker 
implements them (mime and location dont have a meaning with non-file 
entities)


-- 
Mr Jamie McCracken
http://jamiemcc.livejournal.com/