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

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Wed Nov 29 23:40:48 EET 2006


2006/11/28, Jamie McCracken <jamiemcc at blueyonder.co.uk>:

>
> 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



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




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
> http://jamiemcc.livejournal.com/
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061129/4eb04781/attachment.htm 


More information about the xdg mailing list