2006/11/29, 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;"> Mikkel Kamstrup Erlandsen wrote: > > Why is it that you are against a dbus object per query? That way you > listen to signal on the object directly and avoid message filtering (and > possible flooding of the bus). More over a a dedicated object is also > easier to bind in the toolkits (as far as I can see atleast). the bus is shared so if you have a separate object dbus is effectively filtering on that object - its no different from setting up a manual match rule to filter on a QueryID > > >     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 > > > > Do I understand correctly in that you mean to use this interface > directly with no toolkit bindings? (I'm not objecting - just inquiring). yes - toolkits already integrate with dbus unless I misuderstood what you mean? toolkits can further abstract and avoid dbus'isms like libtracker but they are not strictly necessary</blockquote><div> You understood correctly. You mean to let apps use that interface directly. I was asking if you intended to wrap that api in a toolkit  dependent client (which you didn't). </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > What about snippets and file/object properties? yes true - we can add those > > >     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) > > > > What about Konq? Does it have any special needs? right we need to get all the *simple* requirements from apps so that the initial searech interface is useful (if not all powerful). If it can address 90%+ of needs then it will succeed.</blockquote><div> Ok. My opinion is this: Create a simple api for direct use. No live queries, just batch deliverance and support for paging (much like the current spec on WasabiSearchSimple). The question on whether to standardize on a simple query (non-xml, maybe beagle-like syntax) language as well remains open. </div> When we have the simple interface in place, create a "live" (or "full") interface to support live queries and what not. This includes a XML query language. This interface is intended for toolkit bindings (think native Client objects in QT/Gobject), but should be usable without these. Cheers, Mikkel </div>