Introduction to D-BUS

[Thiago Macieira]

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?
>
>FWIW, the sample service file in the Specification does say "D-BUS."

Indeed, the naming wasn't consistent until a short while ago, when we 
decided that the official spelling would be "D-Bus".

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

Well, each type, individually (like INT32, STRING, etc.) will never 
change. If they do, we'll be in a lot of trouble.

Interfaces should be reasonably static, since they are the base of 
communication between two programs. In fact, we tend to 
regard "interface" as the contract between caller and callee: in other 
words, API. So an application shouldn't be in the business of adding and 
removing methods, signals or properties to interfaces while a program is 
running.

Objects can have multiple interfaces and they shouldn't be in the business 
of adding and removing interfaces on the fly either. However, addition of 
interfaces shouldn't break anything -- removal might.

Objects come and go, so they are really dynamic.

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

It does in the parameters. If you send an INT32, you know it's an INT32, 
not a STRING or UINT32.

In fact, the type signature is proeminently placed in the message header 
so that one can query what was passed before trying to demarshall the 
arguments and inspect them.

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

Well, it's similar. In C++, if you declare a function:
	void foo(int, unsigned)
you'll get
	_Z3fooij

In D-Bus, if you call Foo with an INT32 and an UINT32, the message will be 
sent with:
	name='Foo'
	signature='iu'

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

You mean aside from making the users' lives easier? :-)

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060829/d1e95d27/attachment-0001.pgp