DBus for Generic Data Access Methods?

[Marcel Holtmann]

Hi Michael,

> Let's get this back onto a more constructive level.
> 
> We have to distinguish two use cases here, one is using already
> established dbus interfaces (like EDS and Bluetooth) and the other one
> is brainstorming for not yet existing or not widely deployed dbus
> interfaces like.
> 
> I totally agree that dbus API needs to be application driven, however
> there is still reason to talk about syntax and semantics of the
> provided interfaces.
> 
> Marcel, since you seem to have extensive experience with dbus API's,
> what would be your preference based on the two RFC's I posted?

this is actually not easy to answer. The D-Bus design is object oriented
and like in every object oriented programming language you can write
good code and you can write absolutely horrible code. And there are a
lot of grey areas.

The D-Bus specification has some naming conventions. They are not
enforced by D-Bus itself, but there is a general understanding to use
and basically these are borrowed from Java. You also carry always a
domain name around. That is simply fact. The domain name means nothing
for interfaces and path names. It is a simple static prefix. So from the
naming convention perspective the GNOME Power Manager API is more
cleaner and the preferred way.

It is also better to use strings instead of enums or constants like with
my SetMode example.

Every action that changes a state must send out a signal. This allows
you to write fully asynchronous application that can react on events.
With my SetMode example you would need a ModeChanged signal.

Whenever possible a single out parameter is easier to handle and complex
data structures should be avoided.

The one interface per path thing is non-sense. You can have as much
interface for a path as you want. So for example power control and
brightness control can be on the same path, but they use two different
interface like org.openmoko.Brigthness and org.openmoko.Power or
something similar.

The well known bus name also must _not_ match the interface name.

So you basically should look at the hardware at hand and list all the
possible options. Something like an advanced sysfs tree. And then you
should list all the settings that you wanna change from within the UI.
After that you have to decide on the number of daemons that are needed
for these tasks. For example on for GSM, one for GPS one for audio
control, one for Bluetooth and one for systems specific things
(brightness, power management etc.) or even more.

The number of daemons is equal the number of well known names. Every
well known name needs at least one "well known" path. Otherwise you have
to do introspection and you don't wanna do that. On top of the path you
need at least one interface. The rest is adding more interfaces and
creating logical groups for similar functions.

Regards

Marcel