Introduction to D-BUS

[Jeroen T. Vermeulen]

On Tue, August 29, 2006 14:49, Matthew Johnson wrote:

>     - It's spelled "D-Bus" not "D-BUS"

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?

FWIW, the sample service file in the Specification does say "D-BUS."


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


>     - "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?


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

(Well technically of course you could "mangle" the methods' signatures
into their over-the-wire names, like C++ mangles identifiers at the link
level, but I guess that would make interoperability a bit painful).


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

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.

By "different angles" I mean that someone who uses one binding may say
that D-Bus works in one way, and someone else using another binding would
say it worked very differently--because part of what they're describing is
really in those bindings, and they're either not mentioning that or just
not aware of it.  That can be confusing and disorienting to newcomers. 
When people search the Internet for information, they'll probably find
explanations in other languages than the ones they plan to use.  They'll
naturally assume that they can ignore the sample code and pick up the
basics anyway.  That's how I ended up with contradictory information about
proxies.

So if we were to give names to these client-side design choices, we could
say things like "The GLib binding provides two kinds of proxies, one
attaching at creation time and one non-attaching," or "in this binding,
proxies attach at first method call (but they do not attach when listening
for a signal)," and we could all agree on what "attach" means in this
context.

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


Jeroen