IDL language

[Havoc Pennington]

I think a variety of separate conversations and issues are getting
confused here.

* the syntax of the type library. Type library = interface description
used to check types at runtime and/or generate code.
Really, this should be conveniently machine-readable. Therefore XML.
Everyone needs the XML parser for the Introspect() version anyway.

* what is _expressed_ in the type library. Additional annotations such
as struct names and enum names can maybe go here. But orthogonal to
its syntax. The various XML "dialects" are mostly adding new
conceptual info to the type library.

* what is sent over the _wire_. This need not include the struct and
enum names, because both sides should already have the type library,
or implicitly encode the same info the type library would have in the
code that they write. Or generated code can implicitly contain the
type library info (the code is generated from the typelib after all).

* whether generated code considers annotations such as struct and enum
names in order to get static type safety. This is up to the binding,
but should be completely possible given the right info in the typelib.

* what syntaxes you can generate a type library from. You could
convert from CORBA-like IDL (which iirc even had a "compiled"
machine-readable form?), or you could convert from a language as
Qt/moc and g-ir-scanner do, or you could write XML directly, all of
these are worth supporting.

* specifically, whether to have a corba-idl-like syntax for authoring
type libraries. I have no objection to that, but it's just a syntax.
It shouldn't affect any of the above.

* whether to replace the XML with a corba-idl-like syntax. I think
this is bad because XML is easier for most of us to work with, and
people who like IDL can author in IDL regardless. And because XML is
sort of a longstanding already-existing thing in dbus-land.

XML here is like the binary typelib format in gobject-introspection.
It's not something you are supposed to be typing in. People have just
been too lazy to write code scanners or IDL parsers to generate the
XML. Well, the solution to that is to write the scanners or IDL
parsers.

Havoc