DBus for Generic Data Access Methods?

[Marcel Holtmann]

Hi Jim,

> 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.

I have no idea what you are meaning with this. The D-Bus object path is
only a name and it actually doesn't matter what it is. The object path
from the dataserver is as fine as any other path.

> 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.).

You don't subscribe to signals. The signals are broadcasted to the bus.
However you can setup what signals should wake up your process.

> 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.

Actually that is the total wrong approach. You first think about
possible applications and then analyze their needs. The application
needs are essential to design a good D-Bus based API. Think of tasks
that you wanna fulfill with your application and then you have to design
an interface with methods and corresponding signals for that task.

Regards

Marcel