DBus for Generic Data Access Methods?
Jim McDonald
Jim at mcdee.net
Mon Jan 29 20:51:34 CET 2007
Michael 'Mickey' Lauer wrote:
[...]
> I want to have dbus access for everything (that makes sense) as well, i.e.
>
This is fantastic; just what I hoped to see. The one thing that I see
as critical here is a logical translation layer (e.g. applications use
'/org/openmoko/contacts' instead of
'/org/gnome/evolution/dataserver/addressbook' and either something does
a translation on-the-fly or we get the applications to listen to the
OpenMoko path as well as the product-specific one), otherwise moving
from one application to another is just too difficult and we end up with
lock-in.
One thing I do like about DBus is that it was very much designed with
hardware events in mind. A lot of the ideas on the wiki would be so
easy to do with DBus containing both hardware and application
publishers/subscribers. Picking one at random, say the ambient noise
dependent ringing volume, if there was one app that sampled the noise
levels now and again and published the result to
/org/openmoko/environment/externalnoiselevel or whatever then any app
could subscribe to this and change its volume accordingly. This means
that rather than having ambient noise dependent ringing volume you have
ambient nose dependent 'phone volume for any 'phone app that cares about
this (or perhaps you have another app that controls a master volume
depending on a number of items such as currently selected profile,
ambient noise level, time of day etc.).
Anyway, if it has been decided that DBus is the way to go then I do
think that the next step would be to generate a set of object paths,
methods and signals that would form the contract of the various
applications. That way, even with people coding without the hardware or
other people's applications in front of them they will have a good level
of interoperability.
Cheers,
Jim.
More information about the openmoko-devel
mailing list