[Phone Server dbus API]: sync vs. async

[Nuutti Kotivuori]

Michael Lauer wrote:
> as you might know I'm working on the dbus API for the forthcoming phone
> server. There's a conceptual disagreement about whether to use a mainly 
> synchronous or mainly asynchronous API, e.g. would you rather call a method 
> that returns the results or call a method that triggers a signal that will 
> eventually come.
>
> The synchronous API may be simpler to follow, however the asynchronous API is
> more natural since both the modem and the UI are basically event-based 
> models.
>
> However, it looks like 90% of the existing dbus APIs are using the
> synchronous approach.
>
> This decision is quite important as it lays out the base for the
> phone server architecture and possibly eventually a reimplementation
> of the gsm 0707 backend.
>
> Please give your input -- for reference, the current state of the
> dbus API can be checked out with:
>
> svn co svn://projects.linuxtogo.org/svn/smartphones/trunk 

I am a bit confused as to what is actually being asked here.

DBUS is intrinsically asynchronous - method calls can be made while
waiting for the results of a former method call and requests and
replies can be interleaved arbitrarily.

In an API sense, this means that every dbus method call may
independently have a reply_callback and an error_callback - and the
API doesn't force the user to wait for the results to a method call
before issuing another.

So, if this is the case, what would be the rationale in a method call
returning immediately and the actual reply coming later on via a
signal? All this seems to do is obfuscate obtaining the results - and
is prone to all sorts of problems like not remembering to signal
errors as well and causing the client to wait for the signal
indefinitely. And clients who actually do need to call the method in a
blocking manner will have to build their wrappers that wait for the
signal to come before returning.

On the other hand - if the interfaces being exposed are naturally more
signal based than method call based, then it probably just complicates
things to try and make them behave like method calls.

However, looking at the API now, for the most part I think method
calls will work just fine.

-- Naked