IDL language

[Havoc Pennington]

Hi,

On Fri, May 8, 2009 at 4:04 PM, David Zeuthen <david at fubar.dk> wrote:
>
> No amount of so-called XLST "sugar" is going to fix how you actually
> describe the service in the first place. Unless you write it in an
> IDL-ish language and then transform it to (some dialect of) D-Bus
> introspection XML.

That's precisely what I meant when I said IDL should be just another binding.

If you want to write IDL, write IDL. Then convert it to the
interoperable XML typelib format.

MyInterface.xml: MyInterface.idl
    dbus-idl-to-xml $< --output $@

dbusxml_DATA=MyInterface.xml
EXTRA_DIST=MyInterface.idl

Done!

Then, anyone can also use the IDL with any generated-code language
binding; if all the language bindings support generating from xml,
then you do IDL to XML, then XML to generated code files.

If you implement all the converters as a single tool suite, you can
also bypass the XML and just go through an in-memory parse tree
representation (the dbus-glib-tool code in dbus-glib was, long ago,
intended to be this many-to-many converter thing, where it would
support converting each language and IDL and typelib format to an
in-memory parse tree, and then from the in-memory parse tree out to
each of the formats).

But, I think the way things naturally work is that the XML-to-language
converters come with those particular bindings, rather than fitting
into a unified tool. Also the language-to-XML scanners. So the natural
things to have in the unified tool are only the IDL and the XML.

Havoc