IDL language

[Mark Doffman]

Hi David,

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

Yeah, having thought about it a bit more this situation is different to
the discriminated union. With the discriminated union the construct can
be re-created within the existing IDL. (Even more so if hints are
provided as to where the discriminator is). Thats not the same with the
dynamic_struct.

In an Ideal world ABI compatibility could be maintained by appending
attributes on to the end of structs. This breaks 'C' ABI, but not
necessarily D-Bus. If all marshalers were written to ignore un-used
elements at the end of all D-Bus containers (Which they should be) then
this should work fine. There are probably lots of marshalers out there
that don't do this, including some of mine, so the dynamic_struct
solution is certainly the safest.

I just wonder whether we should be encouraging people to write
marshalers that ignore unknown elements at the end of containers, rather
than creating a rock-solid, but more complicated, solution.

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

Thanks,

Mark