[Phone Server dbus API]: sync vs. async

[M. Dietrich]

hi,

On Wed, Jan 30, 2008 at 03:27:00PM +0100, Michael 'Mickey' 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.

i am currently working on a stack of daemons needed for a mobile
device. most daemons are written in python to allow fast adaption on
changing requirements in the api or easier search for best behavior.

all daemons already use d-bus and make mostly use of signals to
deliver data.
> 
> 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.

i dont agree, that a synchron aproach is simpler to use. maybe it's
the old discussion of using thread or not. glib is a wonderful tool to
build concurrency in a threadless world (all my daemons are based on
glib and all but one do not use threads).
> 
> However, it looks like 90% of the existing dbus APIs are using the
> synchronous approach.

this may be the cause i did a different design: i don't use existing
dbus apis alot.

maybe i can give some samples:

	a gps daemon receives location via udp (from gllin in our case) in
	nmea format.

	it interprets these nmea sentences. if the position changes it
	signals that over dbus.

as i understand, signals on dbus are quite expensive, because they are
delivered to all connected processes. they are not filtered because
there is no 'subscribe' to a signal.

anyway this way is better than polling for changes.

but what if a client starts after the signal for the current position
is already send? i implemented dbus-methods that demands sending a
signal with the current information.

i use this model for all daemons and their status information. you can
get gsm state the same way. just read the signals or ask the daemon to
fire one if you are lost.

for now all three gsm-states (modem information like vendor or imei,
sim information like pin-state or imsi and network state like signal
quality, registration or cell-id) are delivered this way. while the
first does not change until you change your modem the second will
usually change once if you unlock you sim and the last will change all
the time. i just didn't want to invent another model for the first
case.

some functionality is implemented as method. functions that answer calls
or dial numbers are for shure methods. the result of those methods are
async by the way. you will get the information if you got an connection
via dbus signal.

best regards,
	michael