IDL language

[Havoc Pennington]

Hi,

On Fri, May 8, 2009 at 11:14 AM, David Zeuthen <david at fubar.dk> wrote:
> I think we have seen that this doesn't really work

None of the reasons it doesn't work have to do with the syntax:

>  o  No-one really installs introspection XML anywhere. And if they did,
>    it would probably be a dialect anyway.

Solutions:
 * specify how to install it in the spec
 * specify the dialects in the spec
 * patch stuff to install the xml

Orthogonal change:
 * change the syntax

>  o  For example the online-desktop D-Bus APIs don't even _have_
>    introspection XML because it's all defined in code.

Because it wasn't intended for use by "third parties" really, iirc.

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

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.

> Of course if you hate the very idea of generating code

I do ;-) but I'm not trying to stop anyone from complicating their
makefiles and bloating up their code ;-) I just don't want to build it
in as a mandatory thing the way CORBA did.

> FWIW, just the other day when I was talking to Jon McCann about this, he
> told me that he had once spent quite some time figuring out how the
> online-desktop D-Bus interface worked (he was doing this as part of
> researching some stuff related to directory services). This involved
> looking through the code.

Sure it would be great if every piece of code anywhere in the desktop
had docs and was a well-supported interface, but it should not be
mandatory to write a bunch of docs and IDL just to get something
working that may not even be a public API.

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.

The way I think it should ideally work with Java, C, C++, etc. is that
you write a native object perhaps with magic comments, and at build
time, that gets converted to the XML or IDL and then installed. So
other bindings can then access it, but you never have to hand-write
some annoying format. It's exactly the same idea as
gobject-introspection.

> So there is real value in having an official IDL language. It's just
> easier all around than using D-Bus introspection XML. It makes it a lot
> easier to actually have a discussion on xdg-list.

I'm not against having an IDL language, but I think it should convert
to the XML format, just as specifying an interface in any other
language binding would do. In other words, if I want to specify an
interface, I can write raw XML; I can write in my language of choice
and have a scanner/generator spit out the XML gobject-introspection
style; I can write IDL and have the XML spit out from that; etc. It
doesn't matter where the XML comes from.

> Everyone who write non-trivial D-Bus services with non-private
> interfaces already extends D-Bus introspection XML (we have seen this:
> Telepathy, ConsoleKit, DeviceKit-*), this is just an effort to
> consolidate all this work.

Consolidating that would be standardizing the content and installation
of the XML. A separate IDL format is a separate effort to change the
syntax. What I'm saying is, I'd treat alternative syntaxes just as a
C++ or Java or whatever interface declaration is: an alternative
syntax.

But XML is really nice for interoperability. Otherwise, everyone has
to deal with something like libIDL. And redo bindings that already
work.

> Of course, no-one can force anything upon anyone, if you really don't
> want to use IDL or if your service is private/internal you'd just not
> use it. Simple as that. I'd still encourage you to use IDL though since
> it will help you write more solid services. But that's just my opinion.

Again, as long as the IDL is another "binding" (a way to generate the
XML), then I don't have a problem with it. I would just caution
against treating it as the interoperability format. It's just another
syntax for people who like it the IDL-style syntax.

Havoc