<br><br><div><span class="gmail_quote">2006/11/26, Jos van den Oever <<a href="mailto:jvdoever@gmail.com">jvdoever@gmail.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>> > I'm not a d-bus expert, but at least with the qt4 bindings, it seems that<br>> > you have a choice of waiting for the reply to a d-bus message, or be called<br>> > later when it arrives. There doesn't seem to be anything inherently
<br>> > synchronous in d-bus, so I would imagine that other bindings or adaptors<br>> > have similar capabilities.<br>><br>> Technically correct, this is a feature of the low-level D-Bus library.<br>>
<br>> However this is a different use case.<br>><br>> The asynchronous D-Bus call is for getting _the_ result later.<br>><br>> The use case discussed here is slightly different (unless I am<br>> misunderstanding) it is about returning _some_ results later.
<br>><br>> Example: a user searches through a lot of emails. The program should be able<br>> to display results as soon as possible. At this point the results do not need<br>> to be complete, matches can trickle in when found.
<br>><br>> An asynchronous call would still have to wait for all results, i.e. a<br>> completed query. The user would have to wait for the slowest match.<br>><br>> An option would be to have the initial query call return a query identifier
<br>> instead of results and results would be transported by D-Bus signals using<br>> this identifier as a reference.<br>><br>> A bonus would be to have the possibility of cancelling a query using this<br>> identifier. The user might already have found what they were looking for and
<br>> cancel the search operation in their program. An ongoing searching operation<br>> would not be a problem for the program (it can just ignore any further<br>> results), but it could be hard to explain to a user why their harddisk keeps
<br>> accessing files like mad.<br><br>Exactly. And having live queries is similar to this.<br><br>I'm not the best person to propose an asynchronous language because<br>Strigi has only synchronous queries at the moment. If there's a good
<br>API, i might change that according to that API.</blockquote><div><br>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.
<br><br>Cheers,<br>Mikkel<br></div><br></div><br>