[Phone Server dbus API]: sync vs. async
marcel at holtmann.org
Thu Jan 31 21:10:10 CET 2008
> 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
the XML files a D-Bus introspection and they are a proper API
specification. Check the D-Bus specification for details.
And D-Bus is always async. Even what looks like sync calls is async.
> 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.
In case of D-Bus it doesn't complicate things at all. And an extra
library around a D-Bus API is unneeded. Some people like wrapper and
abstraction libraries, but that is simply not needed. I like to tell to
go back into the Windows world ;)
> 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.
Async, yes. Wrapper library, no. Actually the wrapper library is in most
cases the cause for errors.
More information about the openmoko-devel