Re: GLib plans for the next cycle

[Mark Doffman <mark doffman codethink co uk>]

Hello Everyone,

There has been some discussion about an IDL for EggDBus. I have also
recently started working on a D-Bus IDL so would like to get some
feedback on the syntax and how well the IDL would fit when generating
EggDBus bindings.

I have been working on D-Bus AT-SPI and the IDL is born out of
frustration with the way in which this large and complex D-Bus protocol
is currently documented.

Suffice it to say that I agree with David; a D-Bus IDL is neccessary.
When I began the AT-SPI D-Bus project I did not hold this opinion and
thought that D-Bus XML with extensions was a reasonable way to define a
protocol. (We currently use Telepathy D-Bus XML) As its size is very
large this spec has become unreadable in XML, difficult to modify, and
will require some effort to translate into a decent documentation format.

I feel that the D-Bus introspection XML is used badly. For writing a
D-Bus specification there is too little information to understand a
protocol. Although numerous extensions have been made (Qt, EggDBus,
Telepathy) these are all incompatible. For someone like me, writing a
D-Bus specification that may be mapped to all of these it means
re-writing or adding extensions to the spec for all of the possible
bindings. This was not a valid solution. The D-Bus IDL will solve this,
providing a translator for the IDL into EggDBus XML, TelepathyXML and Qt
XML.

On to the syntax:

My idea for the IDL syntax is to remain close to the 'C' family of
languages, and is most places to C#.

Elements can be namespaced using:

namespace {
	
}

But this should not necessarily translate into a D-Bus interface.

Interfaces are created by:

interface {

}

The basic types of the IDL are those of D-Bus, for example uint32 & variant.

New types can be created using:

struct structName {
	uint32 Name;
}

enum enumName {
	VALUEONE = 1,
	VALUETWO = 2,
}

typedef structName[][] ArrayOfArrayOfStructName;

Methods are declared by:

method methodName {
	enumName anenum;
} reply {
	structName astruct;
} throws (ErrorOne, ErrorTwo);

Both the throws and reply clauses are optional, but if a method does not
have a reply it should not have a throws clause.

Signals are declared using:

signal signalName {
	structName astruct;
}

errors are similar:

error errorName {
	structName astruct;
}

There should also be a 'using' statement that has similar properties to
the C# statement.

In general the design philosophy for the IDL is to provide the bare
minimum of added concepts on-top of D-Bus needed to document a D-Bus
protocol. These extra concepts are those of named errors, structs, enums
and named method and reply elements.

Specifically excluded are things like unions that could be mapped to
D-Bus in very many ways depending on the bindings.

Probably the most controversial element of this syntax is that methods
are not described using normal method syntax. This is to make utterly
explicit that D-Bus methods are nothing more than a message type. And
D-Bus nothing more than a message passing system. This IDL is describing
message types, not function call types. When I started using D-Bus the
notation of <method> <arg/> </method> fooled me into thinking that D-Bus
methods were function calls, and as such synchronous. I want no-one new
to D-Bus to make that mistake again.

The immediate criticism I imagine I will face when creating a D-Bus IDL
is that we are re-creating CORBA. This is not the case. The D-Bus IDL
has NO defined mapping into language bindings. They serve only to
provide readable documentation for a D-Bus protocol. They may also help
language bindings, providing hints as to how the protocol should be mapped.

When the IDL is (far) more complete the AT-SPI D-Bus protocol will be
translated into it. Currently there is an incomplete and bare grammar
available at git://git.codethink.co.uk/git/didl.git. The grammar is in
antlr3 format, so it is easy to generate a recognizer for it. There is
also the beginnings of an AST grammar.

I'd welcome all feedback on the syntax, and basic philosophy behind the
IDL. I'm very interested in translating into EggDBus XML as this will
make it easier to create new 'C' bindings for AT-SPI D-Bus. I'd like to
know if there is any information missing that would make this difficult.

There doesn't need to be one IDL to rule them all, people designing
D-Bus specifications are free to choose the format they like.

Thanks

Mark