DBus for Generic Data Access Methods?

Marcel Holtmann marcel at holtmann.org
Fri Feb 2 12:04:57 CET 2007


Hi Rob,

> > 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.

constants are always complicate in higher level languages. Not from the
implementation point of view, but from the making generally available
point of view. I don't wanna dig through a huge list of constants to use
a D-Bus API from within Haskell for example. I simply wanna use it.

> > 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.

Let me repeat myself "Every action that changes a state ...". I didn't
speak about asynchronous method calls. And these are even possible with
the low-level bindings.

> > 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)

Even if it is possible, it doesn't make it better. The possibility to
return multiple return values is not as optimal as some people might
think. I prefer to avoid it whenever possible. And there exists always a
weak link in the chain and my assumption is that the dbus-glib bindings
will be mostly used.

> > 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.
> 
> Yes :)
> 
> > The well known bus name also must _not_ match the interface name.
> 
> Not true.

Oh yes it is true. The interface names and well known bus names can be
different. It only happens to be used this way and I personally don't
prefer it at all. I always pick the domain part to be the well known bus
name.

This is exactly the problem in the D-Bus examples that make people think
they can only have one interface per object path.

> > 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.

It is possible, but I've never seen any such use case. However it might
become in handy if you combine daemons into one binary like busybox or
something. Otherwise I think it is a bad design.

Regards

Marcel






More information about the openmoko-devel mailing list