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

[David A. Wheeler]

Havoc Pennington wrote:
> 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.

Generating code from the XML does seem like a logical
next step, though.

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

XML is already easily extensible if you simply ignore
attributes & elements you don't "understand".
Separation might be a good idea, though I'm not sure what you have
in mind.


> i.e. NO_REPLY_EXPECTED is not a property of the callee or interface,
> it's a property of the caller.
> ...
> 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.
...
> Receivers are required to reply unless NO_REPLY_EXPECTED is set.

Ah - that needs to be clearly stated in the tutorial & specs.
Is this requirement to reply enforced by the bus?

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)?


(Talking about error replies attached to methods)
> 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.

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.


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

Oh, I completely agree.  But you can simply say that if an
interface is deprecated, everything inside is deprecated,
and that the "deprecated" mark isn't required on each slot inside.

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.

We may have different ideas about how "frozen" an interface is.

--- David A. Wheeler