[Phone Server dbus API]: sync vs. async

Rodolphe Ortalo rodolphe.ortalo at free.fr
Wed Jan 30 21:58:13 CET 2008


Hello,

I second Alexandre position.

However, I am not really proficient with DBus way of doing async calls.
I've just looked at the .xml definitions of the standards/ subdir in the
SVN repo you indicated, but that's not totally easy to read, and there
are also python-ism and vala-ism in the software area so I found a
little difficult to find the actual programming API. What is the
reference exactly (I suspect that the .xml files are, but could you
confirm)?

IMHO, an asynchronous interface is suitable in this case, especially
when dealing with communication-oriented device/daemon. (For things like
the phonebook access, this is probably more questionable; but your main
point was the GSM I guess.)
It may complicate the way a programmer has to interact with the service
for the simpler tasks (esp. if it involves registering with DBus
signals, etc.), but this should be hidden by a library.

E.g. in a library I expect calls like these (in pseudo code) for
function:
  result_data* fct1(inputtype1 arg1, inputtype2 arg2)
implemented asynchronously.
 I usually like the idea of using the notion of request handle and
spliting functions of the API in 2 parts, like here:

 myhandle = fct1_start(input1,input2);

then getting back the result with (blocking by default):

 result_data* theresult = fct1_get_result(myhandle, NO_OPTION);

or just for checking if fct1 has completed:

 result_data* maybetheresult = fct1_get_result(myhandle, NO_WAIT);
 if (maybetheresult == NULL) {
   /* Argh, she always puts her Neo anywhere... let's wait 2min more */
 } else {
   /* Hmmm, why does she answered so fast? */
 }

Of course, a synchronous access can be implemented pretty easily then:
result_data* fct1(inputtype1 arg1, inputtype2 arg2) {
	return fct1_get_result(fct1_start(arg1,arg2), NO_OPTION);
}

So, personnally, I'd favour an asynchronous API, with companion
libraries to simplify usage if common tasks are really cumbersome and
repetitive (ie: error prone) to write.

Just my 0.02 of course.

Rodolphe

Le mercredi 30 janvier 2008 à 15:59 +0100, Alexandre d'Alton a écrit :
> Hi,
> 
> 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.
> 
> Regards,
> 
> Alex.
> 
> 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 openmoko-devel mailing list