DBus for Generic Data Access Methods?
marcel at holtmann.org
Tue Jan 30 12:49:18 CET 2007
> > - 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
> 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.
More information about the community