Re: GLib plans for the next cycle

[Havoc Pennington <havoc pennington gmail com>]

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.

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

Havoc