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
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.
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
