2006/11/28, Jamie McCracken <<a href="mailto:jamiemcc@blueyonder.co.uk">jamiemcc@blueyonder.co.uk</a>>: <div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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</blockquote><div> 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 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... Cheers, Mikkel </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 <a href="http://jamiemcc.livejournal.com/"> http://jamiemcc.livejournal.com/</a> _______________________________________________ xdg mailing list <a href="mailto:xdg@lists.freedesktop.org">xdg@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/xdg"> http://lists.freedesktop.org/mailman/listinfo/xdg</a> </blockquote></div>