Errors and the introspection format
hp at redhat.com
Mon Feb 20 08:10:42 PST 2006
On Mon, 2006-02-20 at 10:19 +0100, Thiago Macieira wrote:
> Thank you for this clarification. After re-reading the spec, I can see
> this requirement there too. I just suggest adding a couple of capital
> MUST to the paragraph about this. :-)
The spec could use a lot of improvements ;-) it's a bit... "informal"
> > - this annotation should not appear in introspection results.
> > it's not a property of the interface/server, it's a property
> > of the generated code desired by the app programmer on the client
> > side.
> Why not? When introspecting a remote object to make a dynamic call (i.e.,
> not generated code), the binding could use this information to determine
> whether it should set the no-reply flag in the call or not.
What I would say is that noreply isn't really a property of the method,
it's a property of how you want to call it. e.g. if I have:
then sometimes maybe I want to block and know that it was invoked
successfully, and sometimes maybe I don't care. But I think it's the
caller app that knows this.
That's the rationale anyway, maybe it's wrong.
> I don't think this is a good idea. It would introduce more elements into
> the XML definition.
You're probably right
> However, the D-Bus specification should list the well-known annotations
> that do have a meaning for all implementations -- and only those. NoReply
> and Deprecated are such cases. It may list other annotations as examples,
> but it should make it clear that they are not "well-known" and that they
> are specific to one single implementation.
> The way I read it, by definition, any annotation can be safely ignored. If
> it is supposed to carry some information that should not be ignored, it
> should not be an annotation.
Good points. I think it's good to have notes about
implementation-specific annotations, but it should be clear that other
bindings can ignore them.
More information about the dbus