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

[Havoc Pennington]

On Sat, 2005-02-05 at 21:44 -0500, David A. Wheeler wrote:
> 
> <!-- Set oneway="yes" if this method doesn't (normally) reply;
>       callers should send their message with NO_REPLY_EXPECTED: -->
> <!ATTLIST method oneway CDATA "no">

This is in CORBA because the IDL is used to generate stubs/skels. So it
would go in the introspect format when we add the code generation stuff
(along with things like the name of the native function, etc.). So far
we aren't using this format for code generation.

i.e. NO_REPLY_EXPECTED is not a property of the callee or interface,
it's a property of the caller.

I think we may want to put these "code generation hints" into the
introspection data in some sort of clearly separate way, and maybe also
an extensible way, so that any binding/tool can insert its own hints
into the format. Something like the extensible attributes in C#.

> I'm basically looking through CORBA, seeing what
> might be worth stealing for D-BUS.  A key method
> attribute in CORBA is "oneway" (similar to NO_REPLY_EXPECTED).

In dbus (I think correctly) this is a property of how the caller chooses
to invoke the interface, not a property of the interface itself.

> If a caller sends to a message expecting a reply, and the
> receiver doesn't normally reply, the caller will get instantly
> stuck.

Receivers are required to reply unless NO_REPLY_EXPECTED is set. If the
flag is set, they can reply if they want, but the caller will probably
ignore the reply. (The bus eats these replies by default even.)

>   Whether or not there's a reply is _DEFINITELY_ information
> the introspection data should include, because callers will sure
> want to know!

The reason they know is that there's always a reply unless the caller
gave permission to skip it.

> I agree that the list will be incomplete... but so be it.
> I'd rather have partial information than none at all.

I think the info for humans belongs in docs and comments. If we put it
here, people will try to use it in bindings (e.g. to generate "throws"
clauses) and since the information will be consistently wrong, that
would be pretty bad.

> > I did decide the deprecated attribute could be useful, so I left it
> > there, with one change: the default is now the deprecated status of the
> > containing interface. So that was a small DTD change to remove the
> > default from signals, methods, and properties.
> 
> Why?  I would expect it'd be more likely to
> deprecate a specific method/signal/property, instead of an
> entire interface.

Yes, but if you deprecate an entire interface you should not have to
manually add the deprecated attribute to every member of the interface.

Havoc