Mikkel Kamstrup Erlandsen wrote:
2006/11/28, Jamie McCracken <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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/
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
