On Monday 11 February 2008 13:07, Michael 'Mickey' Lauer wrote: > Thanks for all your mails on that subject. > > Now that I understand that due to the inherent asynchronous nature of dbus, > it's actually merely a matter of how the application choses to use the API. > Which makes me confident my first API draft is actually not too bad. > > Two followup questions on that though: Since both methods and signals can > be called asynchronously, when should we broadcast and when not. Right now > I have chosen signals for status changes that potentially could be > interesting to multiple applications. I did not use signals for returning > phone book entries or SMSes (although the arrival notification is of course > a signal) -- I tend to think broadcasting these results is over the top -- > what do you think? > > Marcel, if you have a chance, I'd appreciate if you could take a look at > the complete API as it stands in svn and comment on that. > > Cheers, > > :M:
I was under the impression (possibly wrongly) that the broadcast would actually only take place if there was a listener. If there's no listener, no broadcast. So putting the ability for an application to listen out for these things might be useful anyway. What if, for example, when I put in a new phonebook entry I want a backup made automagically on my sd card or if I want to archive all my SMS's automagically... just examples of course, but I think the point is make them all available for use. Of course if my understanding of how dbus works is wrong please correct me. Andy