Introspect data from Python missing return parameters

[Daniel P. Berrange]

I've been doing some interoperability testing of the Perl bindings, and 
noticed a problem with the introspection data returned by Python services.
While it provides information about the input parameters on methods, it
omits information about the return parameters. Taking the 'example-service.py' 
program, it returns

<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" 
  "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node name="/SomeObject">
  <interface name="org.freedesktop.DBus.Introspectable">
    <method name="Introspect">
    </method>
  </interface>
  <interface name="org.designfu.SampleInterface">
    <method name="GetDict">
    </method>
    <method name="HelloWorld">
      <arg name="hello_message" type="v" />
    </method>
    <method name="GetTuple">
    </method>
  </interface>
</node>

Which is basically saying all its methods have no return value. In the Perl
bindings I had assumed that introspection data is basically complete, or
absent altogether. If present, I use the introspection data for return types
to sanity the method reply contents. Hence with the return types missing, 
the sanity checks abort the caller. 

I expect to receive something closer to:

<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
  "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node name="/SomeObject">
  <interface name="org.freedesktop.DBus.Introspectable">
    <method name="Introspect">
      <arg type="s" direction="out"/>
    </method>
  </interface>
  <interface name="org.designfu.SampleInterface">
    <method name="GetDict">
      <arg type="a{ss}" direction="out"/>
    </method>
    <method name="GetTuple">
      <arg type="(ss)" direction="out"/>
    </method>
    <method name="HelloWorld">
      <arg type="s" direction="in"/>
      <arg type="as" direction="out"/>
    </method>
  </interface>
</node>


For weakly typed languages this isn't really too critical whether the
return types are there or not, but strongly typed languages which 
use introspection data to auto generate API bindings would be handicapped. 
Thus I think it would be useful to fill out the spec on introspection
to make it explicit about the semantics of the data provided. 

 * Is it compulsory to list all interfaces ?
 * Is it compulsory to list all methods/signals within an interface ? 
 * Is it compulsory to list all parameters/return types for a method ?

Personally I'd like the answer to be yes for all of those questions,
since it makes it possible to sanity check usage in the client code
to provide explicit & informative error messages to the programmer.

Regards,
Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20051006/0f12d7d9/attachment.pgp