Using corba IDL to describe DBus services ?

[Havoc Pennington]

Hi,

Jacques Guillou wrote:
> As far as I know, defining a data structure is not possible with the 
> current introspection format. The only thing you can do is to define a 
> method which takes a structure as a parameter, but you can't give this 
> structure a name that the stub generators will use to generate a C 
> struct or a java class. Is that right ?

There's a subtle point here. In CORBA when you define a struct you 
aren't defining a name, you're defining a _type_. That is, there's a 
type system that spans the various application processes. If you have 
struct Foo { int i; } and struct Bar { int i; } in CORBA, those are 
_not_ interchangeable.

D-Bus on the other hand does not have the cross-process type repository. 
So the signature of a D-Bus method will not have "struct Foo" in it, but 
rather "a struct with one integer"

D-Bus punts the problem of treating this struct-with-one-int as a type 
to the individual binding. So for example, as Thiago says, a binding may 
allow you to annotate that you want to use an existing type like QPoint, 
or it may allow you to annotate that you want to generate a struct and 
name it Foo or Bar. But D-Bus itself doesn't care on either the protocol 
or libdbus level.

The introspection format _is_ an IDL - but the standard tags in it 
define only the minimum information for interoperability, and then on 
top of that an individual binding can add annotations that further 
specify how to generate code.

One reason is that ideally, users of bindings do not have to write IDL. 
The best bindings will allow people to just write objects, perhaps with 
annotations (as in java annotations), or magic comments for languages 
lacking annotations. These objects would then be automatically converted 
into the appropriate D-Bus introspection xml.

> Basically, we need to build a system out of many DBus services (written 
> in different languages), which exchange some complex data structures.
> Therefore we need a way to describe these data structure and generate 
> some C/C++ headers, java files, and DBus stubs out of these definitions.
> Wouldn't it be good to use a corba IDL syntax to describe the APIs, with 
> some modified stubs generator which produce the DBus bindings ?

You could certainly do a "CORBA IDL binding" in effect, or your own 
cross-language binding that generates headers for multiple languages. 
You could even have a "type repository" of some kind layered on D-Bus.

One thing we probably should do is establish a method for installing 
clean introspection files so users of static languages can generate 
proxies at compile time. This is a kind of limited compile-time-only 
type repository. I think there's quite a bit of discussion in the 
archives about how this might be done, but not sure there are any 
patches yet.

> Isn't it a problem encountered during the migration of GNOME or KDE to 
> DBus ?

I believe DCOP did not have separate IDL files, it just scanned the 
QObjects (the same way I mentioned a D-Bus binding would ideally work). 
GNOME did not use IPC nearly as pervasively as KDE, in part because I 
think the CORBA IDL approach made it too clunky, which means it was 
relatively easy to port.

> How are the dbus APIs from these desktop applications defined ?

People have to write docs (there's no standard mechanism yet though a 
nice proposal was posted recently which I guess we need to try and move 
forward).

Also the APIs should be runtime-introspectable to get the minimum 
information to be able to marshal a call, though the runtime 
introspection generally does (and should) lack binding-specific 
annotations for code generation.

In any case, it's possible to build stacks and stacks of extra stuff on 
D-Bus (type repos, IDL, other features), it's just a matter of whether 
there's really reason to do so and whether anyone wants to start a 
project to do it. From what I've seen many uses of D-Bus are pretty much 
making a single method call or connecting to a couple signals so 
anything very complex feels like major overkill for many apps.

Havoc