DBus for Generic Data Access Methods?

[Jim McDonald]

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.