D/BUS IDL compiler ...

[Havoc Pennington]

On Wed, 2004-03-10 at 06:03, Michael Meeks wrote:
> 
> 	;-) although not so hard. Ultimately, I'm persuaded we have to have IDL
> as the authoritative, standard contract definitions, rather than parsing
> C headers (and/or perl,python,-whatever language the service is
> implemented in- to try and extract interface data / documentation from
> that).

Rather than IDL seems sensible for the _installed_ interface
descriptions if any to be the Introspect() format, for reasons just
discussed in my other mail. Installed descriptions should be used only
at compile time though I think to generate headers; i.e. be considered
part of the -devel package. At runtime it seems appropriate to me for a
binding to call Introspect() instead.

The virtue of COM/CORBA-style IDL is familiarity and ease of writing by
hand, and so I think IDL is essentially a specific kind of binding,
where you can write your IDL contract and then generate code from it. Or
generate the XML format from it and have other bindings able to generate
code from that.

Again the intermediate XML format is for ease of binding implementation
and Introspect() string generation, basically. The syntax is simpler and
more recursive/machine-readable/machine-generatable than IDL.

Also of course I do think many people won't be writing IDL and should
not have to. In Qt in particular it makes no sense as the QObject
already has full introspection data associated. And there's no reason a
GObject can't have this as well. So this is why I say IDL is a specific
binding to dbus, where you decide to write out your object in IDL rather
than writing it out in a native programming language.

Another thing to keep in mind is that there's no type inheritance in
dbus (or DCOP I'm pretty sure). QObject, QWidget, QComboBox are just
three separate interfaces. Though if you invoke a method on that object
instance it will automatically go to the right interface, so the object
instance can be passed around as if it were any of these types.

In short we aren't trying to enforce the typing of objects at the dbus
level, there is no type repository with a mapping from interface/struct
names to IDL, and there is no type checking at the protocol level. It's
all in the binding.

Booting the type system out of dbus in this way makes the core system a
lot smaller and simpler, and keeps the bindings friendly to the native
type system of the binding.

Havoc