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

[Jos van den Oever]

2006/11/28, Jamie McCracken <jamiemcc at blueyonder.co.uk>:
> Adam Lofts wrote:
> > Hi,
> >
> > On 28/11/06, *Magnus Bergman* <magnus.bergman at observer.net
> > <mailto:magnus.bergman at observer.net>> wrote:
> >
> >     Is it only realistic
> >     that users would want (or should be able) to do such simple searches? I
> >     think it's realistic to imagine that there can be different search
> >     engines which are good at different things. Perhaps one is good at
> >     finding media files by their tags. One that is good at finding relevant
> >     information from fuzzy terms.
> >
> >
> > The multiple search engine problem seems to be the perfect use case for
> > dbus naming. Each search engine registers a well known unique name e.g.
> > "org.novel.Beagle.simple"  and tries to own "org.freedesktop.search.simple".
> >
> > Thus if I want to be picky about who to query I ask for the engine
> > specific name, and if I don't care (surely the common case) I ask for
> > the well known name. Wrapping a library around this would be fine, but
> > the main point of the spec needs to be defining this interface
> > ("search.simple") and getting everyone to implement it.
> >
> > On 28/11/06, *Magnus Bergman* <magnus.bergman at observer.net
> > <mailto:magnus.bergman at observer.net>> wrote:
> >
> >     At least I see it there has to be some kind of daemon if there is a
> >     dbus interface.
> >
> >
> > Use dbus activation.
> >
> >
>
> thats what I have been saying to mikkel (in private). We really dont
> need a lib/daemon

DBus activation does not solve the problem of finding the right search
engine for a particular query. The vision of having many different
search providers, where the disk indexers are the most important ones,
is one that requires this.

> Also I agree with most of what Joe Shaw has said on this thread
>
> We should punt query language and metadata names to a later spec and
> concentrate on getting a very simple implementation going first.
True.

> 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
What do you mean with 'dynamic interfaces'? We are not talking about
interfaces that change, but about busses that will have a dynamic
number of objects.

> 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

I see no value in a PrepareQuery method. If the search engine has a
need for caching, it can use the query as an ID. The functions
ExecuteQuery and QueryHitCount are contradictory. The first one is
asynchroneous and the second one synchroneous.

> signal QueryHitAdd (ID i, uri s)
> signal QueryHitRemove (ID i, uri s)
For performance reasons, these queries should return multiple URIs at once.

> The above is easy to implement and should cover the simple ground
True, but I dont think it is radically different from the interface
that has been discussed before. Please have a look at what's there now
and help to build on that.

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

They could be separate methods, but the requirements are also
adequately covered by the current proposal.

Cheers,
Jos