Michael 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. > > 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. > > However, it looks like 90% of the existing dbus APIs are using the > synchronous approach. > > This decision is quite important as it lays out the base for the > phone server architecture and possibly eventually a reimplementation > of the gsm 0707 backend. > > Please give your input -- for reference, the current state of the > dbus API can be checked out with: > > svn co svn://projects.linuxtogo.org/svn/smartphones/trunk
I am a bit confused as to what is actually being asked here. DBUS is intrinsically asynchronous - method calls can be made while waiting for the results of a former method call and requests and replies can be interleaved arbitrarily. In an API sense, this means that every dbus method call may independently have a reply_callback and an error_callback - and the API doesn't force the user to wait for the results to a method call before issuing another. So, if this is the case, what would be the rationale in a method call returning immediately and the actual reply coming later on via a signal? All this seems to do is obfuscate obtaining the results - and is prone to all sorts of problems like not remembering to signal errors as well and causing the client to wait for the signal indefinitely. And clients who actually do need to call the method in a blocking manner will have to build their wrappers that wait for the signal to come before returning. On the other hand - if the interfaces being exposed are naturally more signal based than method call based, then it probably just complicates things to try and make them behave like method calls. However, looking at the API now, for the most part I think method calls will work just fine. -- Naked
