Introspection & compound type signatures

[Daniel P. Berrange]

On Sat, Mar 19, 2005 at 11:52:25PM -0500, Colin Walters wrote:
> If we agree that the problem we're primarily interested in solving is
> making introspection XML easier to write, then this solution makes
> sense.
> 
> However, it seems to me that there's other places where you potentially
> want an "expanded" format, such as in dbus-viewer, or your "dpack"
> thing.  And that format probably shouldn't be XML, or it's a bit too
> expanded for those uses :)

Once the introspection stuff is working, i plan to remove the 'dpack'
function, since it'll result in simpler & clearer code to just define
the introspection data for the APIs being provided. I agree that if
defining introspection data in the app code you wouldn't really want
to use XML. I plan to have 2 ways to define introspection data when 
providing an object to the bus.

a) just pass the file name to the introspection xml file into the 
   constructor of the object.

    package Org::Example::SomeObject;
    
    use base qw(Net::DBus::Object);
    
    sub new {
        my $class = shift;
	my $self = $class->SUPER::new(object_path => "/org/example/SomeObject",
	                              interfaces => ["org.example.SomeInterface.xml"]);
    }

    The xml file would be located & loaded from some standard location in
    a similar manner to which the '.service' files are currently located & 
    loaded. It might be handy to have some standard location for all bindings
    to use if they wanted to allow XML introspection data to be provided 
    external to the source code.

b) provide the introspection data inline in some convenient language
   native format, for example when defining an object, rather than
   just passing in the list of methods to export, pass in a data
   structure. For example
   
    package Org::Example::SomeObject;
    
    use base qw(Net::DBus::Object);
    
    sub new {
        my $class = shift;
	my $self = $class->SUPER::new(object_path => "/org/example/SomeObject",
	                              interfaces => {
                                        "org.example.SomeInterface" => {
                                           methods => {
                                             "helloWorld" => {
	                                         params => ["string"],
                                                 returns => [["array",["string"]]],
                                             },
                                             "getDict" => {
                                                 params => [],
		                                 returns => [["dict", ["string", "string"]]],
                                             },
                                             "GetTuple" => {
	                                         params => [],
                                                 returns => [["struct", ["string","string"]]],
                                              }
                                            },
	                                  },
                                      });
    }

    In this example its obviously useful to have standard for expanded type
    names (eg 'string', 'array', 'dict'), but the actual way the type structure
    is defined is I think best handled in the language specific format. In
    this case, the perl data structure would be serialized to XML on the fly
    by the impl of Introspect method in the base class.

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: 232 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050320/c6cfc069/attachment.pgp