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

[Mikkel Kamstrup Erlandsen]

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.

Do you have any specific idea for a dbus interface?




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