DBus for Generic Data Access Methods?
rob.taylor at codethink.co.uk
Fri Feb 2 13:37:19 CET 2007
Marcel Holtmann wrote:
> 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.
I don't understand what you see as the difference between 'digging
though' a list of valid string values, or looking up a valid constant name.
>>> 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.
My misunderstanding :)
>>> 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.
I'm afraid I wasn't clear that time. My reply was to 'and complex data
structures should be avoided', I strongly disagree with this, as it has
resulted in ill-defined and inefficient APIs. if your data is complex,
use a complex type, don't do crazy workarounds just because the bindings
need fixing, as then when the bindings are fixed you have a api that's
messed up for no good reason. The correct solution is to join in on
helping to fix the bindings.
>>> 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
They certainly can be different, and indeed be the same - they're
different name spaces. It is certainly not the case that "the well known
bus name also must _not_ match the interface name".
On whether interfaces should be namespaced by domain, I believe so (as
do most other people working with dbus apis) as this helps in having
generated bindings without clashing namespaces.
> This is exactly the problem in the D-Bus examples that make people think
> they can only have one interface per object path.
I completely agree the dbus documentation leaves a lot to be desired,
again, dbus has a very open team, so any help writing HOWTO's and
extending documentation is appreciated.
>>> 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.
If a process is providing a number of services, it makes complete sense.
Whether its a good design choice or not completely depends on the code.
The point I'm making is its not a requirement.
More information about the openmoko-devel