Hi Rodophe, > > > 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 > bindings. 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 really overhead. Regards Marcel
