DBus for Generic Data Access Methods?

[Marcel Holtmann]

Hi Kalle,

> >    - Current DBus object paths are application-centric (this is by 
> > choice of the application)
> > [..snip..]
> >    - There seem to be two options (ignoring the uninteresting ones):
> >       - take a combination of the existing application-centric paths and 
> > make it available somewhere as a reference guide
> >       - create a new set of paths which form an OpenMoko standard and 
> > are adhered to by all (friendly) apps that run on OpenMoko
> > 
> 
> I agree to this completely. Especially the second option, when thinking
> about openmoko as a device with features and the custom-programs sending
> events to governing services via dbus.. This all needs a layer of some
> kind, something that defines the different services a little. Namely the
> paths, of course.
> 
> For example, when thinking different gps-states (or phone states for
> that matter).. when application needs a more precise location, it'd send
> a message via dbus, wanting to change gps-state to use more resource for
> better positioning (or faster tracking). I'd favor having a wrapper for
> the paths. Having system-dbus working as a set standard would really be
> cool. But it should also be designed to accomodate changes in the
> features (no gps in some openmoko platform).
> 
> Or maybe by just having a definition of it in a sense of 'this is where
> it would be should we have a feature like this' is not a bad thing at
> all.
> 
> As always, dbus is still there for the hardy-coders that want to use
> application-centric paths.

does anybody actually read my comments on how D-Bus works and that the
persistent focus on the path is completely irrelevant.

I know that understanding D-Bus is hard and I also had my problems in
the beginning. It simply works different.

Regards

Marcel