2006/11/28, Jamie McCracken <<a href="mailto:jamiemcc@blueyonder.co.uk">jamiemcc@blueyonder.co.uk</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Adam Lofts wrote: > Hi, > > On 28/11/06, *Magnus Bergman* <<a href="mailto:magnus.bergman@observer.net">magnus.bergman@observer.net</a> > <mailto:<a href="mailto:magnus.bergman@observer.net"> magnus.bergman@observer.net</a>>> 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* <<a href="mailto:magnus.bergman@observer.net"> magnus.bergman@observer.net</a> > <mailto:<a href="mailto:magnus.bergman@observer.net">magnus.bergman@observer.net</a>>> 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) </blockquote><div> 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).  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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</blockquote><div> 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?  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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)</blockquote><div> What about Konq? Does it have any special needs? </div> </div> Cheers, Mikkel