Hi Rodolphe, > 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)?
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. Regards Marcel
