2006/11/26, Jos van den Oever <[EMAIL PROTECTED]>:
> > 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
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
