[Phone Server dbus API]: methods vs. signals

[Andy Powell]

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