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

[Jamie McCracken]

Mikkel Kamstrup Erlandsen wrote:
> 2006/11/28, Jamie McCracken <jamiemcc at blueyonder.co.uk 
> <mailto:jamiemcc at blueyonder.co.uk>>:
> 
> 
>     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
> 
> 
> 
> You mean that the client app will have to do dbus match rules, no? I see 
> that this would work, but it also feels counter intuitive, and all 
> experience tells me that this should be avoided in an api.
> 
> Why not use temporary dbus objects instead? That will also wrap easier 
> in a toolkit client object. Then you have the search engine live interface:
> 
>   method org.freedesktop.search.live.PrepareQuery(args) : returns a dbus 
> path to the query object

yes that will do - I was worried the existing interface would be 
extended dynamically but yeah using a separate interface will avoid that

> 
> The query object has the interface org.freedesktop.search.Query 
> something like:
> 
>   method org.freedesktop.search.Query.Execute (args)
>   method org.freedesktop.search.Query.HitCount (args)
>   method org.freedesktop.search.Query.Close (args)
> 
>   signal org.freedesktop.search.Query.HitAdd (args)
>   signal org.freedesktop.search.Query.HitRemove (args)
>   signal org.freedesktop.search.Query.HitModify (args)
> 
> This is a really rough draft, but I hope the point is clear enough...
> 

yeah thats fine.  (not sure you need a HitModify though?)

HitAdd - only fired when a new file is created that matches the query
HitRemove - only fired when a file is deleted that matches the query

For a file Move - it generates a remove and an add signal.


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