IDL language

[David Zeuthen]

On Fri, 2009-05-08 at 19:46 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Fri, May 8, 2009 at 11:59 AM, David Zeuthen <david at fubar.dk> wrote:
> > Sure, they are mostly useless. But what about people who wants to
> > consume your service from, say, C or C++?
> 
> struct names can be in the _IDL_ (which may have corba-idl-ish syntax
> or xml syntax or binary syntax, irrelevant for this point). They don't
> belong on the wire, in the protocol. 

I, actually, never suggested all this extra stuff would go on the wire.
In fact, I've argued pretty strong that IDL != D-Bus introspection XML.

> > 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".
> 
> Horrible hack, imo, that has no business existing. If you're sending
> types over the wire like this, then something in the way you're doing
> things is _wrong_, because both sides of the conversation should
> _already know the type_ ... they both need to know the interface
> contract to begin with or you couldn't have written the code! So why
> put this on the wire? It can only be due to some sort of design bug.
> 
> OK, there's one exception: if you put this in a variant, i.e. you have
> an interface contract that involves RTTI.
> 
> I guess my basic view is that making all of dbus an uglified complex
> type-repository-requiring hell in the mold of CORBA, just to support
> using structs in variants for generated-code bindings, is a bad
> tradeoff. ;-) Because the _only_ time you need this type tag is when
> you want to bind to a generated struct type (rather than some sort of
> generic hash table or tuple), and you have a variant so the interface
> contract does not already specify the type.
> 
> So I'd punt here. C++ programmers can use a map<string,variant>
> instead of a struct AtaSmart, when said hash appears as the value of a
> variant. In return, we can save thousands of lines of code and
> complexity.
> 
> But, short of values in variants, I think you get what you want
> without putting this in the wire protocol. You just need it in the
> _IDL_, not on the wire. And you can still have statically-declared
> struct types in generated code.

Bingo, that's why both sides (the client and the server) need to use the
IDL to generate code for handling normal structs and also a{sv} which is
what everyone with public APIs are going to use except for the very
simple stuff or unstable/private API.

Or if you refuse to use IDL, at least you can look in an IDL file what
the heck this or that a{sv} is supposed to contain.

> > 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).
> 
> It just does not come up with JavaScript - it's a complete non-issue,
> because there aren't any static types.

Well, good luck using the NetworkManager, Telepathy and DeviceKit-disks
and lots of other APIs from gjs then. Because all these APIs already (or
will in the future, in the case of DeviceKit-disks) use a{sv} for things
where you'd normally use a struct. Except for very simple stuff of
course.

This is simply because these D-Bus services don't want to lock the API
down, who knows, maybe in the case of ATA SMART or Filesystems we
pretend to support we need to add some field somewhere in the future
(very likely). 

You may not like this, but this is just the harsh reality of how people
use D-Bus. Do you think this is _wrong_?

That said, I'm not sure why it's not possible to generate JS code that
unpacks said a{sv} and presents you with a struct-like object with
getters and setters.

> But again, look: nobody is stopping you from doing an IDL syntax, in
> fact it was in the original plans many years ago, and is one reason
> the old dbus-glib binding tool thing was going to have multiple
> input/output formats.
> 
> All you do is write an idl2xml thing; and then in your source tree,
> you just have IDL; and you have a little makefile rule to build the
> XML and install.

I'm not opposed to translating IDL to XML but the output is going to
look just as ugly (actually uglier) as the hand-written dialects that I
posted links to elsewhere. 

E.g. you need a way to represent struct, dynamic_struct, enum and what
not if you don't want to throw away information and leave API consumers
looking elsewhere for what the heck the a{sv} variable of the week
means.

You'd also need to get everyone already invested in D-Bus introspection
XML to agree with these extensions.

Sure, both things are feasible, just not sure it's worth it. More
importantly, what's the _point_ in such an exercise?

> > 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
> 
> $ dbus-xml-to-idl
> /usr/share/dbus-1/idl/org.freedesktop.DeviceKit.Disks.xml | less
> 
> is not really that bad.

Any exactly why wouldn't I just look at the IDL instead? And if this
would ever work, then the XML files in /usr/share/dbus-1/interfaces
would look different from what's on the wire because they would need to
contain more information than what you transmit on the wire.

     David