simple search api (was Re: mimetype standardisation by testsets)

[Mikkel Kamstrup Erlandsen]

2006/11/29, Jamie McCracken <jamiemcc at blueyonder.co.uk>:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061129/01640f8a/attachment.htm