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

[Jos van den Oever]

2006/11/28, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> 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
> because
> > > > > > > Strigi has only synchronous queries at the moment. If there's a
> good
> > > > > > > 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
> gui
> > > > > can show results pretty quickly even if the query is slow.
> > > >
> > > > In Beagle, all searches are inherently asynchronous.  The client sends
> a
> > > > 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
> large
> > > > 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.
> a
> > > music browser, or filemanager.
> > >  2) There should be no query building on the application end. Just pass
> the
> > > 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
> code
> > >
> > > The plan was that when we had a simple interface we would move on and
> define
> > > a more advanced one for people with the need for this.
> > >
> > > The problem is that 2) warrents a simple search language to be defined
> to
> > > 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?
No, first do the synchroneous simpel API. But adding a simple
asynchroneous API when the synchroneous is successful is a good idea.

> 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?
Spawning an object is probably cheap. Its not much different from
allocating some memory. The object is not advertized on the wire. It
just sits there, collects results and passes them on the the client.

Cheers,
Jos