IDL language

[Mark Doffman]

Hi David,

>> 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
> something).
> 
> For your consideration:
> 
> eggdbus xml for org.freedesktop.DBus:
> http://cgit.freedesktop.org/~david/eggdbus/tree/src/eggdbus/org.freedesktop.DBus.xml
> 
> DeviceKit-disks xml for org.freedesktop.DeviceKit.Disks.Device:
> http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/tree/src/org.freedesktop.DeviceKit.Disks.Device.xml
> 
> Yeah. Really ugly. I know! And it gets worse if you codify existing
> practices like dynamic_struct. Which everyone and their mother is using
> already.

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:

git://git.codethink.co.uk/git/didl

The ideas behind this IDL were explained at on the Gtk mailing lists a
little while ago.

http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00006.html

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

Thanks

Mark