Introduction to D-BUS

[Matthew Johnson]

On Tue, 29 Aug 2006, Jeroen T. Vermeulen wrote:

> Ah.  I'd consistently written "DBus" originally, but then standardized on
> "D-BUS" based on some of the documents linked from the project page.  Has
> the Tutorial changed its spelling of the name recently?

Yes, we recently standardized as there was some disagreement.

>>     - " If you use the simple call-and-wait style (synchronous
>>       invocation), any other messages that come in while you wait will be
>>       queued up and delivered to your program when it's ready for them."
>>       again, depends on the binding. The Java binding is reentrant; all
>>       method calls are executed in a different thread. Actually this
>>       means that all calls are asynchronous at the libdbus level, but at
>>       the Java API level they are not.
>
> So it may fire up a new thread to handle an incoming request while other
> threads are still working on previous method invocations on the same
> object?  If so, I'd better mention that or people could get themselves
> into a lot of trouble with hard-to-reproduce symptoms.

The Java binding will. Multiple threads is a standard Java solution (all
the normal I/O is blocking) and it provides a lot of ways to deal with
concurrency. Other bindings default to a deadlock problem and force you
to write your own reentrancy.

>>     - "An object's type remains unchanged over the object's lifetime, as
>>       do the interfaces themselves: an object's set of methods and
>>       interfaces is fixed." This is an entirely sensible thing to do, but
>>       I don't think it's proscribed anywhere? Static languages like Java
>>       make changing this hard, but more dynamic languages may not.
>
> But this bit is all about D-Bus typing.  Does it hold true for D-Bus
> objects/interfaces/methods?

I was just pointing out that there is no reason that an object should
not gain or lose interfaces throughout its lifetime.

>>     - "There is no overloading, as in some programming languages: every
>>       member name must be unique within its interface" I don't think this
>>       is true, certainly The Java binding supports it. It is as sensible
>>       as allowing overloading on interface name imho (and easier to
>>       implement in Java).
>
> How does the Java binding support this?  From a cursory glance at the
> spec, I wouldn't have thought that there was anywhere for the message to
> encode this difference...

When I get a method call I lookup the object in a table. If it exists I
look at the parameters that I have received and their types. I then
lookup methods on that object with that name and type signature. Java
can reflect at runtime on the type signatures of methods and dynamically
invoke the correct one.

>> Most of these may be distinctions you don't want to go into in this
>> tutorial, I'm mainly checking you realize the difference and it's a
>> conscious choice, rather than a misunderstanding.
>
> Some of them are.  In fact I am definitely incorporating them into the
> text.  I'd like to have a bit more than just a vague conceptual overview.
> I'm trying to get as much in there as is possible without making it a hard
> read and without becoming specific to a particular binding.

It gets quite difficult after a point when the bindings implement things
subtly differently. Some of this is philosophical differences between
the authors and some of it reflects the normal coding paradigms in each
language.

> Maybe eventually some of the design differences between bindings can be
> named so we can easily describe the main characteristics for different
> bindings.  That may make it easier for bindings authors to describe them,
> but it also reduces the "different angles" problem I've been running into.

This sounds like a good idea.

> When people search the Internet for information, they'll probably find
> explanations in other languages than the ones they plan to use.

Ideally there should be a tutorial and in-depth documentation for all of
the bindings. I've tried to do this with the Java binding.

> Are there any standards for what bindings should or should not do, by the
> way?

I have just finished specifying a test suite for bindings. This
specifies a series of tasks that programs written in the binding should
be able to do (as a DBus interface), but not how these should be
presented to the programmer; that is a language specific thing. Things
like sync/async, reentrancy, name or peer binding for proxies, whether
things are done with actual objects or a bunch of separate objects etc
are up to the binding author for how they think it fits the language
best. We encourage the bindings to allow either option (most of them
provide some sort of sync or async behaviour).

The test suite is available in git at
git://anongit.freedesktop.org/git/dbus/dbus-test and has brief
documentation (including the interfaces required) at
http://dbus.freedesktop.org/doc/test/

Matt

-- 
Matthew Johnson
http://www.matthew.ath.cx/