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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list