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

[Havoc Pennington]

On Sun, 2005-02-06 at 08:06 -0500, David A. Wheeler wrote:
> Ah - that needs to be clearly stated in the tutorial & specs.

"When an application handles a method call message, it is expected to
return a reply. ...
If a METHOD_CALL message has the flag NO_REPLY_EXPECTED, then as an
optimization the application receiving the method call may choose to
omit the reply message (regardless of whether the reply would have been
METHOD_RETURN or ERROR). However, it is also acceptable to ignore the
NO_REPLY_EXPECTED flag and reply anyway."

> Is this requirement to reply enforced by the bus?

The bus can't enforce it since it can't distinguish no reply from slow
reply.

> And if callers start to rely on that, there's the issue of crashing apps.
> I don't understand what's supposed to happen when a
> receiving application crashes without replying to a message
> where a reply IS expected (NO_REPLY_EXPECTED == false).
> The bus can detect when a crash occurs & alert others, but
> does that mean you can't really just wait for a reply
> (because you need to watch for the crash)?

This is an orthogonal issue to oneway, since you will always have !
oneway which will have this issue.

The way it works is that:
 - there's a timeout on your method call
 - if the connection breaks you immediately get an error reply generated
   by either your local DBusConnection object or the bus, depending
   on the details

Anyhow you don't have to do this manually.

> Okay, I see your concern.  How about defining error types WITHOUT
> attaching them to any particular method, since you think that people
> won't accurately attach them anyway?  That way, at least the
> error reply parameter types and names will be identified.

This is the same problem as defining struct types. I'm not opposed to
it. We can add this once we're prototyping code that would use it.

Right now fields beyond the error string in errors are purely
hypothetical; the glib bindings don't and won't really support them for
example because GError doesn't.

> My thought was: what do you do if an interface is fine, but you want to just
> deprecate a single method, property, or signal?  Allowing a
> "deprecated" mark for just one method is just the ticket.

I kept the deprecated attribute for single interface members. What I
changed is that the default is the deprecation status of the interface,
rather than "no"

Havoc