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