[Phone Server dbus API]: sync vs. async

Alexandre d'Alton alex at alexdalton.org
Wed Jan 30 15:59:33 CET 2008


As a Software Architect in a cellular company, I can say that the mainly
async behavior is the only way to address all potential problems. I cannot
details cause I'm afraid to say too much.
But in any cases, consider that it's almost impossible to 'fake' async
behavior from sync apis whereas creating sync apis from async is really
straight forward.



On 3:27 pm 01/30/08 Michael 'Mickey' Lauer <mickey at openmoko.org> wrote:
> Hi,
> 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

More information about the gsmd-devel mailing list