DBus for Generic Data Access Methods?
rob.taylor at codethink.co.uk
Fri Feb 2 11:33:40 CET 2007
Marcel Holtmann wrote:
> 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.
I'd disagree with this statement. Its *much* more efficient to use
constants, as as long as you have the same care with constants as you
have with constants you export in an abi, there's no down sides.
> 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.
No. Any decent binding will allow you to make method calls
asynchronously. You only need signals where a number of clients need to
listen to the state change.
> Whenever possible a single out parameter is easier to handle and complex
> data structures should be avoided.
No, again this depends on the binding you're using. The glib bindings
are a bit unwieldy with the more complex data types, but you gain a
well-defined interface. BTW, the glib bindings are fixable and in the
future (when one of us gets the time to work on them...) they should be
able to marshal complex types into structures of your choosing. I should
note that the Python, Qt, Mono and Java bindings are all much better in
this respect (all written after dbus-glib)
> 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.
'Something like an advanced sysfs tree' is HAL. I've just finished a
bunch of work to make this much more suitable for embedded (and will be
doing more), so please check it out before reinventing the wheel. (data
point, it runs at 144K private dirty on a Nokia 770)
> 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.
Not true. One dbus connection can register as many bus names as it wishes.
I should also say that imo, every time you're designing a dbus
interface, you should think how generally applicable it is. I'd like to
start seeing a lot more standardised dbus interfaces on freedesktop.org
(like HAL, Telepathy, Avahi and the various planned XDG interfaces).
Before inventing a new api, its best to look and see what people are
working on already, and seeing how it fits your needs, even if the code
that implements it doesn't.
More information about the openmoko-devel