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

[Jos van den Oever]

2006/11/27, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> 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
>
>
>