IDL language

[David Zeuthen]

On Mon, 2009-05-11 at 15:32 +0100, Mark Doffman wrote:
> There is no easy way to map 'variant' in the 'C' libraries. 

Something like EggDBusVariant works fine for me...

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

The discriminator is in (or will be) the typelib as an annotation.

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

Look at it like this: Do you use structs at all? If so, are you 100%
certain that these structs won't grow in the future? I bet the answer
here is no unless it's really trivial stuff like Point (x, y) or
something very simple.

Anyway, if the answer is no, then you want a{sv} as the on-wire format
so you can add fields in the future without breaking the protocol. You
can easily make this look like a struct so it's easy to access as a
class/struct/whatever from the target programming langauge. Easier to
deal with than a GHashTable, more safe too. Hence dynamic_struct.

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

Don't think there should be an entry keyword at all (but we need to find
a way to cope with the unfortunate fact e.g.  "ss{si}" is a valid
signature. Probably map the third element to a dict<string,int32> (and
only allow one element).

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

An IDL language will need to support anonymous structs, I think... For
GLib we'll probably need to have a GDBusAnonymousStruct class to handle
that.... is also needed for when you use the GLib D-Bus library without
a code generator.

    David