mark.doffman at codethink.co.uk
Mon May 11 01:34:31 PDT 2009
>> If D-Bus was new and not yet as widely used adopting a different
>> language than XML could have been a good idea. But now?
> My experience with several dialects of introspection XML (at least
> three: Telepathy, ConsoleKit/DeviceKit-disks and eggdbus dialects) is
> something I'd rather be without. It's hard to get right, easy to get
> wrong and if you show it to someone, they just give you that blurry look
> like it's Ada or FORTRAN or ask you if you made money on fixing Y2K bugs
> in a previous life. So, no, D-Bus introspection XML is not something
> that _I_ want to show to a new person on my team, for example (not
> unless I wanted them to nominate me as the PHB on The Daily WTF or
> For your consideration:
> eggdbus xml for org.freedesktop.DBus:
> DeviceKit-disks xml for org.freedesktop.DeviceKit.Disks.Device:
> Yeah. Really ugly. I know! And it gets worse if you codify existing
> practices like dynamic_struct. Which everyone and their mother is using
I'm in complete agreement here. I have a problem with writing XML for
describing the D-Bus protocol. Take a look at the xml folder in
git://git.freedesktop.org/git/at-spi2/at-spi2-core.git for a reason why.
AT-SPI is a big API and when converted to Telepathy XML makes for a
completely unreadable & unmodifiable spec.
Added to this I need to write bindings for the AT-SPI using multiple
languages and bindings. To do that I have to add Qt & Telepathy
annotations to the spec, making it even more of a mess.
Born out of my experiences of this I have started a D-Bus IDL. The code
can be found at:
The ideas behind this IDL were explained at on the Gtk mailing lists a
little while ago.
Not that much work has happened on the IDL since then, but the modules
system is close to completion and the IDL should compile to D-Bus
introspection XML very soon.
I understand that you have your own ideas for what an IDL should look
like, but I'm willing to modify what I have to accomodate them. I'm also
willing to put in the work to complete a decent IDL parser and translator.
> As previously explained, there is a need in D-Bus for both
> 1. an "exchange format" describing a service (D-Bus introspection XML)
> mostly used for dynamic languages to facilitate method calls,
> receiving signals and values coercing into and back from the native
> type system; and
> 2. a format used for describing and documenting a services (IDL)
Couldn't agree more. I'd describe this split slightly differently.
1. The message format and its documentation.
2. How these message formats are to be used when binding to specific
libraries / languages.
> I'm not sure that there is a good reason that one and two should be the
> same. In fact, for 1. there's often a bunch of bloat you want to avoid:
> documentation, checked exceptions (e.g. we may want a throws clause in
> the IDL language, I don't know) and other stuff.
I think they shouldn't be the same. The IDL I have at the moment covers
only part 1.
Part 2 I think could be genrally shared for most object-oriented
languages and bindings, but we might not want to standardize it as other
bindings may want to use something completely different.
> In fact, many people punt on 2. - "we'll add the docs later" they tell
> me, very agile and stuff, I know, just not very useful (in my view) for
> production level code.
> Either way, I personally maintain enough complex D-Bus services to make
> this IDL language worth my while. If there's no interest in an official
> IDL language in the D-Bus project, then, hey, less work for me since I
> won't have to care about other implementations or deps like libglib-2.0
> - and I can just make "didl" mean "David's IDL" (or, preemptive snarky
> comment, "Douchebag's IDL") rather than "D-Bus IDL"... since that
> happens to be my name ;-)
Same here. I have to maintain a complex D-Bus interface. I'd like to
create an IDL to do so. Lets work together.
> Hmm, guess I'm being a bit on the defensive here and a bit more
> emotional that I'd normally be. Sorry about that. But I find it very
> hard to contain my hate for writing code in XML and also that of having
> to decipher some D-Bus service because, well, "we'll add the docs later"
> mentality. So there you go.
More information about the dbus