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

[Mikkel Kamstrup Erlandsen]

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



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


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

What about snippets and file/object properties?


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?


Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061129/297b3dbe/attachment.htm