IDL language

[David Zeuthen]

On Fri, 2009-05-08 at 11:29 -0400, Havoc Pennington wrote:
> >  o  You'd be forcing other bindings to use anonymous structs if they
> >    want to access your service. That, or they'd rewrite your XML
> >    to IDL to have non-anonymous structs.
> 
> I don't like named structs on the protocol level. They are a construct
> for bindings that care. They are useless in JavaScript (and imo
> Python).

Sure, they are mostly useless. But what about people who wants to
consume your service from, say, C or C++?

> It's fine to have them as an extra annotation in XML and/or IDL, but
> they shouldn't / don't appear in the protocol, and thus bindings are
> free to ignore them.
> 
> >  o  We are _all_ using a{sv} for extensible stuff instead of a struct,
> >    and you don't have that with D-Bus introspection XML.
> 
> I don't understand this bullet point, but the introspection XML is
> completely extensible, so whatever can be in there.

Sorry, I wasn't sufficiently clear here. The idea is that in IDL you can
write stuff like this

 namespace org.freedesktop.DeviceKit.Disks {

   dynamic_struct AtaSmartAttribute {
     uint id;
     string name;
     byte current;
     byte worst;
     byte threshold;
     array<byte> raw;
   };

   dynamic_struct AtaSmart {
     uint64 time_collected;
     bool passed;
     bool passed_valid;
     array<AtaSmartAttribute> attributes;     
   };

   interface Device {
     GetAtaSmart (out AtaSmart ata_smart_data);
   }
 };

and GetAtaSmart() has a out_signature of (sa{sv}) where the first string
has the value "dynamic-struct:org.freedesktop.DeviceKit.Disks.AtaSmart"
and the dict has the strings "time_collected", "passed", "passed_valid"
and "attributes".

This is a nice construct because for non-private services you want to be
able to add members to structs without changing the on-wire ABI.
Everyone does this (I bet you even do things like this yourself in your
litl APIs) and having this codified is thus a Good Thing(tm).

For example, if I want to use the DeviceKit-disks API from python or
Javascript (and I do), it's *a lot* easier if, hey, I can actually read
some docs explaining this API. Heck, I could even generate proxies if I
wanted to. That would give me completion and other crap if I used a
sufficiently advanced IDE for dealing with this.

> The litl codebase, for example, has loads and loads of dbus that is
> completely internal, and completely JavaScript-to-JavaScript. Having
> to deal with IDL for that is just silly.

This sounds good until you hand over to maintenance of that codebase
over to some team in Elbonia [1]. Or if you decided to open source it.

[1] : http://en.wikipedia.org/wiki/Elbonia

> Consolidating that would be standardizing the content and installation
> of the XML. A separate IDL format is a separate effort to change the
> syntax. 

I'd argued above that a higher-level syntax is needed unless you want to
reverse engineer what different instances of a{sv} means. Stuffing that
stuff into D-Bus introspection XML seems incredibly backwards and
pointless to me. Just make your gobject-introspection scanner output IDL
in the first place.

Also, do not underestimate that it's really nice to just be able to do

 $ less /usr/share/dbus-1/idl/org.freedesktop.DeviceKit.Disks.didl

and actually have a human-readable language that you can read.

     David