IDL language

[Mark Doffman]

Hi David,

> On Mon, 2009-05-11 at 09:34 +0100, Mark Doffman wrote:
>> I understand that you have your own ideas for what an IDL should look
>> like, but I'm willing to modify what I have to accomodate them. I'm also
>> willing to put in the work to complete a decent IDL parser and translator.
> 
> I didn't know you had written a parser for this already. I think it
> would be useful to work on this together; in fact I think it would be
> useful to have a standard "D-Bus IDL" language (and tools) in the D-Bus
> spec module
> 
>  - since we already define interfaces, enumerations in the spec; and
> 
>  - the spec itself already uses a pseudo-IDL langauge; and
> 
>  - doing dbus2idl /usr/share/dbus-1/typelibs/org.example.Foo.xml
>    and getting human-readable stuff is A Good Thing(tm).
> 
> but that's more long term thing and something we can bolt on to the
> D-Bus project should we end up with a really good IDL language. 
> 
> Anyway, right now we have two IDL languages which is not exactly ideal. 
> Some comments
> 
>  - I prefer the use of in/out, e.g.
> 
>     Foo (in  double a,
>          out int32 b,
>          in  int64 c);
> 
>    rather than
> 
>     method Foo {double a, int32 tv} reply {dub}
> 
>    also you can express the former in the latter (ordering might
>    matter, most of the time it won't though). And it's more C-syntax
>    like (and lots of languages are built upon C syntax).

I actually thought this was rather clever. Google protocol buffers uses
the same syntax. I felt like a bit of a rebel. However everyone who has
commented has hated it, so I'm not sure how long it can continue.

The other option is to have out params just as CORBA did. I didn't like
it as its unclear where the initial return value should be placed in the
message. It also has the advantage of not enshrining "method-call"
semantics on the bindings.

I'd be happy to add the 'C' like syntax. Both can co-exist until someone
finally kills the latter.

>  - What do you think of the dynamic_struct construct?

I'm probably against a dynamic_struct. I can see that its useful, but I
had already rejected discriminated unions in favour of just including
variant as a basic type.

There is no easy way to map 'variant' in the 'C' libraries. Which means
I considered adding a 'union' keyword which would always map to 'sv'. I
rejected the idea on the grounds that this would be forcing D-Bus
developers to do something that isn't always necessary. Often the
signature of the variant is enough to work out its type. Sometimes it
isn't and in that case a discriminator would be needed somewhere, but
where the discriminator is should be up to the person writing the protocol.

I'd be opposed to dynamic_structs along the same lines.

I haven't used anything like a dynamic_struct in my work. Which is
probably why I don't think they are basic enough to be included in the
IDL. I'll change my mind if i'm convinced that its something LOTS of
people should be doing in their protocols.

> 
>  - Not sure I like "throws" - most languages don't have checked
>    exceptions, then again, it's actually useful to know what errors
>    a method may throw (in addition to standard network/IPC exceptions).
>    I don't know.

Ummed and ahhed over this too. Declaring the errors was in Telepathy
XML, which is why its included here. As Error-Name is in the message
header there is never any difficulty deciding how to de-marshal the
message. So ATM I'm inclined to agree with you that 'throws' should be
removed. On the other hand it makes for good documentation.

> 
>  - Do you plan to add support for parsing gtkdoc-style docs?

Yes, Absolutely. Its one of the big missing features. Comments are not
included in the AST right now. I need to add them before I can start a
documentation back-end, which is essential.

I should mention here that the IDL has a couple of other missing
features that I intend to add:

Dicts - Not handled at all. I think I'll add an 'entry' and a 'dict'
type. Perhaps they should have template syntax for declaring the types
of keys and values? "dict <string, int32> aDict;". Perhaps there
shouldn't be an 'entry' keyword at all.

Non-named attributes - Hadn't really thought about this until it was
mentioned in one of your e-mails.

Is it a good idea to allow:

struct Unnamed {
	int32;
	int32;
	string cabbage;
}

I guess it is, if someone want to marshal to a custom type. Or for
dynamic bindings that are happy with structs-as-tuples. Its probably
against the spirit of the IDL though.

Thanks

Mark