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 _______________________________________________ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community