Re: GLib plans for the next cycle

[Mark Doffman <mark doffman codethink co uk>]

Hi Mikkel

> 
>> <SNIP>
>>
>>
>> Methods are declared by:
>>
>> method methodName {
>>        enumName anenum;
>> } reply {
>>        structName astruct;
>> } throws (ErrorOne, ErrorTwo);
>>
> 
> If you are so keen on clearing out that this is not really a 'method' then
> why is it declared as such? Why not call it 'message'?

I have misgivings about calling it 'method'. The problem is that
'message' also refers to 'signal' and 'error'. 'method' is the name
given to these types of messages in the D-Bus spec, so it seems
reasonable for it to be the name in the IDL.

> 
> Both the throws and reply clauses are optional, but if a method does not
>> have a reply it should not have a throws clause.
>>
> 
> Is this a limitation of DBus or you spec or the IDL? It seems odd that
> methodTakingEnum(in i myEnum) can not return a DBus error if myEnum is out
> of range...

Not sure. I believe that its really a limitation of the libdbus
bindings. There is not an easy way to have an async method sent and
register a handler for an Error message. Good point though. There isn't
anything against it in the D-Bus specification so I retract that
statement. It now becomes:

Methods can have an optional reply or throws clause.

> 
> And also; can we not call it something other than didl? It is impossible to
> google as there are already tonnes of didls - not to mention the infamous
> Diddl mouse that Google is pretty convinced that I am really wanting to
> search for (which may or may not be correct, but please don't go there)  :-)

Point taken, name will be changed to something more googleable. Messdl?
(Message description language) Something more inventive anyone?

> 
> Anyways I am really glad that someone is looking into this, but I also hope
> that we end up with only one IDL and not N > 1.
> 

Thanks

Mark