Hooks in Base Code

Jim McDonald Jim at devzero.net
Tue Jul 24 12:07:46 CEST 2007


Henryk Plötz wrote:

> Don't worry too much about that right now. I don't know what the
> current plan for this problem is but, given that OpenMoko already uses
> dbus, I'm quite sure that it will include dbus. Going from "I have an
> application that, when a call comes in, pops up a dialog and asks the
> user to accept or reject the call" to "I have an application that, when
> a call comes in, broadcasts a dbus message 'There's a call from ...,
> anyone want to handle that?' and waits for a reply ... 'Anyone? Anyone?
> Ok, openmoko-dialer, your turn'." is easy.
>   
Only if it isn't already hard-coded to go to the dialer in the first 
place, which is why I'm bringing this up now.
> Adding dbus support is *not* the hard part, that's getting calls
> working at all (and of course all the nifty things you'd want to
> plug in, but those are outside of the scope of the base infrastructure).
>   
I agree that adding D-Bus support is not in itself difficult, but trying 
to put the 'right' system in place is not trivial.  You cannot broadcast 
a D-Bus method so you need some sort of mediator in the middle (you 
could broacast a signal but that's fire-and-forget so you then have no 
idea if anyone is even considering replying).  As such you need a 
central arbitrator to handle this functionality.

I've been playing with some code locally in the last few days to get my 
head around this idea, and will write up a few use cases on the Wiki so 
that everyone can see where this is heading.

I understand and agree that making/receiving calls is the most important 
thing right now for the core team but I and no doubt most of the rest of 
the people outside of the core team can't help much there, so if there 
is a way of them being able to build extensions to the will-be 
functionality without getting in the core team's way it should help all 
round.

Cheers,
Jim.





More information about the community mailing list