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

[Mikkel Kamstrup Erlandsen]

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?

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?

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