simple search api (was Re: mimetype standardisation by testsets)
Mikkel Kamstrup Erlandsen
mikkel.kamstrup at gmail.com
Tue Nov 28 12:48:13 EET 2006
2006/11/28, Jos van den Oever <jvdoever at gmail.com>:
> 2006/11/28, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> > 2006/11/27, Joe Shaw <joeshaw at novell.com>:
> > > Hi,
> > >
> > > On Mon, 2006-11-27 at 12:12 +0100, Jos van den Oever wrote:
> > > > > > Exactly. And having live queries is similar to this.
> > > > > >
> > > > > > I'm not the best person to propose an asynchronous language
> > > > > > Strigi has only synchronous queries at the moment. If there's a
> > > > > > API, i might change that according to that API.
> > > > >
> > > > > Exposing the API over DBUS makes your queries async for free (only
> > those
> > > > > requested over dbus ofcourse :-) ). Any dbus call has an async
> and a
> > > > > blocking version, so clients can do what ever they want.
> > > >
> > > > Yes, my point was defining a request that returns the results in
> > > > packets instead of only one reply. This has the advantage the the
> > > > can show results pretty quickly even if the query is slow.
> > >
> > > In Beagle, all searches are inherently asynchronous. The client sends
> > > query request, and a variety of signals are sent back. HitsAdded,
> > > HitsSubtracted, and Finished are the main ones. As long as the
> > > connection to the daemon stays open, events can keep being sent to the
> > > client. Hence, live queries.
> > >
> > > I would suggest a similar setup using unique D-Bus object paths for a
> > > standardized API. (A synchronous API will be pretty darn slow for
> > > queries, I'm afraid.)
> > I think everybody wants that (atleast I do). However the idea about
> > org.freedesktop.search.simple was to have a *simple* interface. Here the
> > simple only applies to the end user-app developers.
> > 1) Targetted at apps where searching is not the main functionality, fx.
> > music browser, or filemanager.
> > 2) There should be no query building on the application end. Just pass
> > string as entered by the user to quuery method.
> > 3) Should be dead easy to drop in your app with only a few lines of
> > The plan was that when we had a simple interface we would move on and
> > a more advanced one for people with the need for this.
> > The problem is that 2) warrents a simple search language to be defined
> > make much sense... 3) is a bit against the nature of your suggestion.
> > A signal driven query response is dead easy to work with when you Query
> > object is a gobject, but when it is a dbus object matters get (a little)
> > more tricky. I'm not totally against this idea (signal driven query
> > response), but I can't see how we could KIS.
> You dont have to define the object in the API. Also having an object
> is independent of the language. It simply means you have something
> with a name on the receiving end. E.g.
> org.freedesktop.search.livequeries/query1. You just define the
> interface methods. I'll give it a quick shot, but agree with you that
> the async API should not go into the simple interface.
> > Do you have any specific idea for a dbus interface?
> In the search API:
> method query(in s query, out s queryid)
> In the livequery API:
> signal moreHits(in hit a(sa(sas)))
> signal finished()
> method closeQuery()
> (basically what Joe proposed)
So you think we should use this instead of the current search.simple api?
What about applications spawning many searches? Think search-as-you-type,
context aware desktop, runtime information clusters... Spawning a dbus
object for each query could become a huge task. I must admit I have _no_
idea on how well dbus scales on multiple private connections... I fear the
answer is "Untested, and expected to be bad". Anyone?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg