Errors and the introspection format

[Havoc Pennington]

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:

 void Frobate()

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.

Havoc