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

[David A. Wheeler]

I'm glad you found the DTD useful!


I think adding the following attribute would be a good idea:


<!-- Set oneway="yes" if this method doesn't (normally) reply;
      callers should send their message with NO_REPLY_EXPECTED: -->
<!ATTLIST method oneway CDATA "no">

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

If a caller sends to a message expecting a reply, and the
receiver doesn't normally reply, the caller will get instantly
stuck.  Whether or not there's a reply is _DEFINITELY_ information
the introspection data should include, because callers will sure
want to know!

Havoc Pennington wrote:
> I removed "raises"; I think there are problems with that, because
> there's really only one language that puts the raises in the type
> signature for methods (Java). I happen to think Java got this right, but
> still, nothing else does it. So when introspecting based on native
> language introspection, the raises clause would normally be bogus...

I know Java, but I didn't do that for Java's sake.
There are two users of the Introspection data, human (programmers)
and computers, and I think they both need data about possible
error returns, such as the error parameter names and types.

If a method throws an error reply,
the receiver will know the D-BUS basic types of the reply, but
without "raises" the receiver won't have other information...
such as the names of the parameters, or the higher-level
types the D-BUS types represent.  If there IS a "raises"
section, then the receiver can use introspection
to get more info about the error it just got (to present
better error information or whatever).

And I expect that one of the users of the introspection data
are human programmers.. who would REALLY like to know what
errors they're likely to get, and the parameters that will
be included with the error replies.

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

I'd prefer that the "raises" info be put back, so that
error replies will be explicitly recorded too.  It _would_
make sense to define errors at the same level as methods & attributes,
and only link back to the errors inside a method, but I think
some way of recording the error replies in the XML would be a
Good Thing.

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

--- David A. Wheeler