DBUS introspection (Was: DCOP interface in kicker broke compatibility?)

[Havoc Pennington]

On Mon, 2005-02-07 at 11:49 +0100, Waldo Bastian wrote:
> 
> Wouldn't it be easier to just say "must not reply"? It seems easy enough to me 
> to check at a relatively low level for this flag so that even when a binding 
> might be inclined to generate a reply on a higher level, it could simply be 
> dropped at the low level before such reply actually hits the bus.
> E.g. dbus_message_new_method_return() could check for it and either simply 
> refuse directly or flag the message to be dropped when it gets to 
> dbus_connection_send().
> 
> I don't see the point in allowing a reply. (Other than for keeping backwards 
> compatibility with a previous version of the spec, but for that purpose you 
> can just say that when you send with NO_REPLY_EXPECTED you must still be 
> prepared to get, and ignore, a reply if it happens to be send anyway.)

You might be talking about something a bit different - David was talking
about requiring that a reply be sent if NO_REPLY_EXPECTED is not set.

I don't think it really matters whether NO_REPLY_EXPECTED is honored, is
the reason I didn't say "must not reply"; maybe there are reasons not to
honor it, for really simple bindings or whatever. It would be hard to
even accidentally break due to receiving an unexpected reply I think,
because you can't really implement dbus in a synchronous way. i.e. you
always have to be prepared to send a call, then get intermediate
messages you may not care about before you get your reply. So "drop
stuff I don't care about" is pretty much a requirement of any
implementation.

That said the bus does automatically eat replies if the caller had
NO_REPLY_EXPECTED set.

Havoc