DBus IDL (Was Re: GLib plans for the next cycle)

[Mark Doffman <mark doffman codethink co uk>]

Hi Havoc,

Thanks for the reply. I have also changed the subject of this which I
should have done in the initial e-mail.

> Hi,
> 
> On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman
> <mark doffman codethink co uk> wrote:
>> Both the throws and reply clauses are optional, but if a method does not
>> have a reply it should not have a throws clause.
> 
> This is perhaps a misunderstanding. All methods have replies (in the
> wire protocol). You may choose to ignore or not wait for the reply, if
> you don't need confirmation that the method message was received and
> handled.
> 
> This should *not* be in an interface description. For a given method,
> one client can call it and wait for reply, and another client can call
> it and ignore the reply. This is just up to the method caller whether
> to do this. But all methods can be invoked in both ways.
> 
> Whether to block for reply is an example of a hint needed for static
> code generation, that is not part of the interface description. I
> would recommend handling this as a command line switch or similar on
> the code generation tool.
> 
> There is a flag on messages that senders can set to indicate they do
> not intend to wait for a reply; this is just an optimization. But note
> it is per-message, not per-message-type.

I take your points completely. Details of waiting for a reply or not
should not be in the interface description. Details of whether to set a
method call as 'no-reply' should not be in this IDL.

When describing this IDL, and in the design, I imagined that all methods
that did not specify a reply should be mapped to a "no-reply" call and
all methods that did specify a reply should generally be sent
asynchronously, but that this would be down to the binding. I now
realize that this is wrong, all notions of how the message are sent
should be binding specific, and provided in hints elsewhere if necessary.

The IDL should only specify the format of the message and optionally the
format of the reply. If no reply format is specified the reply is
assumed empty.

> 
>> 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.
> 
> This seems like a misunderstanding also. How do you think CORBA works?
> It is the same on the wire; it sends some stuff over the socket to
> make a method call, and unless you specify "oneway" (which is brokenly
> in the IDL, rather than the code generator) it blocks and waits to
> know if the method was processed. dbus is exactly the same.
> 
> Whether to block is just a matter of whether you block. You can block
> or not. If you block, you wait to get an "ack" back, possibly with
> return values in it. If you don't block, then you fire-and-forget.
> 
> *libdbus* which is one dbus implementation, encourages you not to
> block, because I consider that more correct and in any case very
> useful. But it does have APIs suitable for blocking as well, like
> dbus_connection_send_with_reply_and_block().
> 
> Anyway, I think there is no difference between method calls and
> message passing. The only difference is in whether the client side API
> is made to look just like a native object. But that's totally
> orthogonal to the IDL and to the wire protocol.

I understand that there is no difference on-the-wire between a
function-call and message passing. The difference is in peoples
perceptions and expectations.

When I read CORBA IDL and see:

int AFunction (int, int);

Because of the connotations provided to me by years of procedural
languages I expect this function call to be synchronous. I hope to break
these perceptions by providing a message-based IDL.

Thanks

Mark