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.

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.

Cheers,
Jos