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