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

[Jamie McCracken]

Jos van den Oever wrote:

Hi Jos,

> 
> DBus activation does not solve the problem of finding the right search
> engine for a particular query. The vision of having many different
> search providers, where the disk indexers are the most important ones,
> is one that requires this.


not sure - I just presume that only one indexing service will ever be 
used by most users. I dont htink there is a requirement for running 
multiple indexers (but feel free to make tracker another backend for 
strigii!)


> 
>> 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.
> True.
> 
>> 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
> What do you mean with 'dynamic interfaces'? We are not talking about
> interfaces that change, but about busses that will have a dynamic
> number of objects.
> 
>> 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
> 
> I see no value in a PrepareQuery method. If the search engine has a
> need for caching, it can use the query as an ID. 

in tracker we have many types of query like "Get all files of a certain 
mime types" which only use sqlite and not our indexer and there would 
also be no search term as such too. Likewise with RDF query so we cant 
really use the query itself as the unique ID.

We store live query results in a temporary sqlite DB so we need a unique 
(integer) ID for those.

Of course I could code around this but it would be more hacky for us to 
do it that way

(The above api is the one we will shortly be using in tracker to support 
live query but of course it may not be suitable for others - thats the 
hard part of standardising!)

The functions
> ExecuteQuery and QueryHitCount are contradictory. The first one is
> asynchroneous and the second one synchroneous.

not really they can both be async or sync

ExecuteQuery returns "limit" hits starting from offset - signals are not 
used here to get results

> 
>> signal QueryHitAdd (ID i, uri s)
>> signal QueryHitRemove (ID i, uri s)
> For performance reasons, these queries should return multiple URIs at once.

they do - these signals are only emitted in response to file 
notifications like a file is deleted or added. Ergo this makes them "live".

No way would we (in tracker) use them for fetching stuff incrementally 
(I may be wrong but I think only beagle currently does that?).

> 
>> The above is easy to implement and should cover the simple ground
> True, but I dont think it is radically different from the interface
> that has been discussed before. Please have a look at what's there now
> and help to build on that.
> 
>> 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)
> 
> They could be separate methods, but the requirements are also
> adequately covered by the current proposal.

I find the current proposal (the spec on freedesktop) a bit too much to 
start with.

Lets concentrate on meeting the requirements of existing apps rather 
than trying to create an open ended system which will be more difficult 
to fashion agreement (at this stage).

If third party apps start using the freedesktop spec then we have a 
platform to build more requirements on and the impetus for supporting 
them becomes greater.


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