Errors and the introspection format
Matthew Johnson
dbus at matthew.ath.cx
Tue Feb 21 04:06:50 PST 2006
On Mon, 20 Feb 2006, Havoc Pennington wrote:
> On Tue, 2006-02-21 at 00:12 +0000, Matthew Johnson wrote:
>> On Mon, 20 Feb 2006, Havoc Pennington wrote:
>>
>>> Possibly the NoReply annotation should have been GLib.NoReply, and
>>> separately we should have a Qt.Async to match the DCOP-compat kind of
>>> feature done in Qt bindings which is slightly different; this would also
>>> help clarify that NoReply is just about bindings and code generation,
>>> not about any intrinsic property of an interface or the wire protocol.
>>
>> surely not GLib, it's useful in other bindings too.
>
> Useful with exactly the same semantic in all bindings?
The current implementation in java (now that I know about the flag) is:
"if the annotation is set when calling a method, set the flag and return
without waiting for a reply"
"if the flag is set when having a method called, call the method and
throw away the result"
I believe this is consistent with the spec description of it. The latter
could be rewritten as:
"if the flag is set when having a method called _and the annotation is
set on the called method_, call the method and throw away the result"
it could be debated either way, I think. My quibble about it being
glib-specific is that it has nothing to do with it being implemented in
C/glib (unlike GLib.CSymbol, which clearly is). I think it may be
specific to bindings which generate code from introspection data
statically; if you can dynamically set the 'noreply' flag you don't need
the annotation. With Java as well as GLib, you can't. This probably
applies to QT as well.
What the contract of it definitely _shouldn't_ be is:
"if the method has the annotation set when it is called, call the method
and throw away the result", since that will break things which didn't
set the flag and were expecting a reply.
Matt
--
Matthew Johnson
http://www.matthew.ath.cx/
More information about the dbus
mailing list