[Phone Server dbus API]: sync vs. async
marcel at holtmann.org
Thu Jan 31 21:39:18 CET 2008
> > > 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.
> _Bad_ wrapper library are cause of errors, like bad libraries (or bad
> OSes... BTW, I am definitely unable to go _back_ to Windows devel.: I've
> never been there personnally).
good for you :) I have seen too much Windows wrapper crap that is
basically only bloat and thus it is no wonder that Windows is so slow ;)
> Of course, if the wrapper library does not really simplify things, it is
> not needed. But when asynchronous execution is involved, some careful
> design/abstraction may help to prevent hard to debug bugs... DBus event
> filtering or signal registration syntax does not seem so straightforward
> to me but I did not look at all binding layers, only raw libdbus or Glib
The libdbus is not that bad, but it is also not convenient. You really
need to know what you are doing. From the client perspective the libdbus
low-level library is actually good enough. From the service/daemon
perspective it is horrible.
Using the GLib bindings is pretty simple. The only issue is if you have
to deal with signal that can't be handled via a pre-defined marshaller.
In that case it actually becomes ugly. Again, not too too bad, but also
not nice. Using GLib bindings for exporting interface is strange to me
since you have to bind it to an GObject. In a lot of cases this is
More information about the openmoko-devel