alternative introspection result format

Daniel Reed n at ml.org
Sat Apr 2 08:50:02 PST 2005


I'd like to look into alternative introspection result formats that use 
DBUS' native hierarchy and types. The goal would be to come up with a 
format that can express all introspection data in a way that a client's 
existing DBUS-message-processing code can be used to decode the hierarchy.

For example, an org.freedesktop.DBus.Introspectable.Introspect call might
return the string:

<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
   <interface name="org.freedesktop.DBus.Introspectable">
     <method name="Introspect">
       <arg name="data" direction="out" type="string"/>
     </method>
   </interface>
   <interface name="org.freedesktop.DBus">
     <method name="RequestName">
       <arg direction="in" type="string"/>
       <arg direction="in" type="uint32"/>
       <arg direction="out" type="uint32"/>
     </method>
     <method name="ReleaseName">
       <arg direction="in" type="string"/>
     </method>
     <method name="ReloadConfig">
     </method>
     <signal name="NameOwnerChanged">
       <arg type="string"/>
       <arg type="string"/>
       <arg type="string"/>
     </signal>
   </interface>
</node>



An alternate introspection call (org.example.introspect) might express 
just input signatures in a native DBUS types, such as:

{
 	"org.freedesktop.DBus.Introspectable" => {
 		"Introspect" => ""
 	},
 	"org.freedesktop.DBus" => {
 		"RequestName" => "su",
 		"ReleaseName" => "s",
 		"ReloadConfig" => "",
 		"NameOwnerChanged" => "-sss"
 	}
}

That is, the initial argument of the reply would be a dictionary mapping 
strings to (dictionaries mapping strings to strings). The first map 
identifies interface; the second layer maps method names to expected 
signature of the incoming message. A special character such as '-' at the 
start of the signature could denote the element was a signal instead of a 
method.



If more complexity is tolerated, another representation may be:

{
 	"org.freedesktop.DBus.Introspectable" => {
 		"methods" => {
 			"Introspect" => ""
 		}
 	},
 	"org.freedesktop.DBus" => {
 		"methods" => {
 			"RequestName" => "su",
 			"ReleaseName" => "s",
 			"ReloadConfig" => ""
 		},
 		"signals" => {
 			"NameOwnerChanged" => "sss"
 		}
 	}
}



Or, to be even more complete:

{
 	"org.freedesktop.DBus.Introspectable" => {
 		"methods" => {
 			"Introspect" => {
 				"in" => "",
 				"out" => "s"
 			}
 		}
 	},
 	"org.freedesktop.DBus" => {
 		"methods" => {
 			"RequestName" => {
 				"in" => "su",
 				"out" => "u"
 			},
 			"ReleaseName" => {
 				"in" => "s",
 				"out" => ""
 			},
 			"ReloadConfig" => {
 				"in" => "",
 				"out" => ""
 			}
 		},
 		"signals" => {
 			"NameOwnerChanged" => {
 				"out" => "sss"
 			}
 		}
 	}
}

The above being a dictionary of strings to (dictionaries of strings to 
(dictionaries of strings to (dictionaries of strings to strings))).



Would any of you be interested in using something like this in your own 
projects? This is not something I am proposing for org.freedesktop.DBus, 
but if any of you on list are interested in working on the format, I would 
love to hear from you.

Thanks,
-- 
Daniel Reed <n at ml.org>	http://naim-users.org/nmlorg/	http://naim.n.ml.org/
There are people who do things and people who take the credit, and the
trick is to be in the first group; there is a lot less competition. --
Dwight Morrow, American Diplomat


More information about the dbus mailing list