[Phone Server dbus API]: methods vs. signals
openmoko at automated.it
Mon Feb 11 14:24:02 CET 2008
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.
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.
More information about the gsmd-devel