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.
_______________________________________________
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
