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

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Mon Nov 27 12:17:31 EET 2006


2006/11/26, Jos van den Oever <jvdoever at gmail.com>:
>
>
> > > I'm not a d-bus expert, but at least with the qt4 bindings, it seems
> that
> > > you have a choice of waiting for the reply to a d-bus message, or be
> called
> > > later when it arrives. There doesn't seem to be anything inherently
> > > synchronous in d-bus, so I would imagine that other bindings or
> adaptors
> > > have similar capabilities.
> >
> > Technically correct, this is a feature of the low-level D-Bus library.
> >
> > However this is a different use case.
> >
> > The asynchronous D-Bus call is for getting _the_ result later.
> >
> > The use case discussed here is slightly different (unless I am
> > misunderstanding) it is about returning _some_ results later.
> >
> > Example: a user searches through a lot of emails. The program should be
> able
> > to display results as soon as possible. At this point the results do not
> need
> > to be complete, matches can trickle in when found.
> >
> > An asynchronous call would still have to wait for all results, i.e. a
> > completed query. The user would have to wait for the slowest match.
> >
> > An option would be to have the initial query call return a query
> identifier
> > instead of results and results would be transported by D-Bus signals
> using
> > this identifier as a reference.
> >
> > A bonus would be to have the possibility of cancelling a query using
> this
> > identifier. The user might already have found what they were looking for
> and
> > cancel the search operation in their program. An ongoing searching
> operation
> > would not be a problem for the program (it can just ignore any further
> > results), but it could be hard to explain to a user why their harddisk
> keeps
> > accessing files like mad.
>
> 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.

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


More information about the xdg mailing list