IDL language

[Mark Doffman]

Hi Havoc, David,

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

Yep, the D-Bus XML describes exactly what goes over-the-wire. This is
the lowest level of information. Pretty much useless for auto generating
language bindings. Any D-Bus IDL should include this information and be
able to compile down to D-Bus introspection XML.

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

I consider structs and enums to be so basic that all language bindings
should be able to make use of them. They are "Annotations" as in they
are not represented in the over-the-wire structure, but they serve to
document the intention of the D-Bus protocol. didl includes structs and
enums in the base IDL.

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

No, of course, the struct and enum names are just documentation /
annotation that may be useful in generating sensible bindings. Shouldn't
be sent over the wire at all. The type information in D-Bus is the
message name or any other crazy scheme the protocol writer decides to
use as type information.

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

Yep, we don't want to go back to the world of CORBA where an IDL had a
FIXED translation in any particular language it supported. I'd like to
be more flexible than that. I'd like to take the 'Base' idl which
documents using annotations such as 'struct' and 'enum' the over the
wire protocol. I'd like to have a separate language for describing
object-adaptor mappings, sync / async calls marshalling ect.

Obviously we can't be super-flexible here. I think the Qt bindings
provide a good example.

For the 'provider' or 'service' side bindings the Qt xml2ccp tool
translates a D-Bus interface to a QDBusAbstractAdaptor.

There isn't much flexibility here, but the extension language should
specify what the C-Name of the abstract adaptor should be.

To use the xml2cpp tool C type names must be provided for all unknown
D-Bus structures. Say I pass a struct (iii) in one of the methods. I
must annotate the XML to declare what C type name this has, then write
marshallers for that type in C++. This is very flexible, I can marshal
things however I want. (As long as they are copyable, value types).
However its also pretty annoying for very basic structures such as
(iii). It would be great for me to have an 'autogenerator' that could
just generate the marshalling code to shove this into a 'C' struct of
name "Time" or whatever the argument is.

The flexibility here is deciding what the C type name is and whether a
standard marshaller should be auto-generated for the type or not.

Other things that should go in a 'Bindings' IDL format are whether
method calls should be made in a syncronous manner or accept callbacks
ect...

Again, enumerations described in the 'Base' IDL don't neccessarily have
to be translated into a language construct, but I can't think of a case
where you wouldn't want to.

So say we have a D-Bus interface (Specified in didl)

interface org.freedesktop.this.is.a.test {
	enum Int16 Status {
		STATUS_ALIVE = 0;
		STATUS_DYING = 1;
	}

	struct Time {
		int32 hours;
		int32 minutes;
		int32 seconds;
	}

	method ping {
		Time time;
	}
}

A separate language used to generate bindings out of this might just say:

org.freedesktop.this.is.a.test.Time {
	autogenerate = True;
	ctype = "QMyTime";
}

org.freedesktop.this.is.a.test {
	client.ctype = "QTest";
	provider.ctype = "QTestAdaptor";
	client.sync = True;
}

The tool that does the conversion might also take as arguments some
defaults on the 'C' type names autogeneration.

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

I haven't been that lazy! I've made a start.

Thanks

Mark