DBus for Generic Data Access Methods?

Rob Taylor rob.taylor at codethink.co.uk
Fri Feb 2 14:22:04 CET 2007


Rob Taylor wrote:
<snip>
> 
>>>> 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.

I should also make it clear that there are *no* complex data types you
cannot use from dbus-glib, its just somewhat awkward at the moment, as
any types returned to you from the bus are marshalled into a type
pre-determined by dbus-glib, which may need some work on you're part to
transform into a datatype useful to your code. One such example is in
the Telepathy spec, dict's are used quite a bit for key-value pairs, and
rightly so as each key may only take on one value. However dbus-glib
will always return a dict to you as a GHashTable, which is a big pain to
iterate on.

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

I should also add one very good usecase - transitioning to a new api,
where you wish to leave the old api available for some time in parallel
with the new.

Thanks,
Rob Taylor





More information about the openmoko-devel mailing list