Proposing ObjectManager interface

[Thiago Macieira]

Em domingo, 27 de fevereiro de 2011, às 07:28:20, David Zeuthen escreveu:
>   <interface name="org.freedesktop.DBus.ObjectManager">
>     <method name="GetAll">
>       <arg type="a(oa(sa{sv}))"
> name="object_paths_interfaces_and_properties" direction="out"/>
>     </method>
>     <signal name="InterfacesAdded">
>       <arg type="o" name="object_path"/>
>       <arg type="a(sa{sv})" name="interfaces_and_properties"/>
>     </signal>
>     <signal name="InterfacesRemoved">
>       <arg type="o" name="object_path"/>
>       <arg type="as" name="interfaces"/>
>     </signal>
>   </interface>

Hello David

For one thing, I'd like to see something us use D-Bus for introspecting D-Bus, 
not have to fall back to XML, which is expensive to produce and/or store and 
then to parse. Having a standardised a{s(iv)} for describing an interface 
would do wonders:

	DICT of STRING to (INT, VARIANT)

where the key (string) is the element name, the INT is the element type 
(method, signal, property, annotation) and the variant contains the element 
description. We'll have to standardise on them too.

I'd suggest that we use the ObjectManager interface for this, but I'd propose 
the following modifications:

	GetAllMatch(in OBJECT_PATH root, in BOOLEAN recurse)
Gets all elements that match a given path root element, and maybe recurse. A 
viewer tool like qdbus, qdbusviewer or d-feet would call 
	GetAllMatch("/", true)
The return value would have to be the full description, for each object. So it 
needs to be a map of object paths to the object description ("a{o?}"). The 
value is the interface description I had above, thus making: a{oa{s(iv)}}.


QtDBus doesn't allow adding or removing interfaces to an existing object 
today, but that's an internal limitation that could be lifted. I'm wondering 
however what's the interest in this. Do others rely on interfaces appearing 
and disappearing on existing objects? I've never seen this.

I think determining object creation and destruction would be a lot more 
interesting.

I still have a question which has plagued me for the entire duration of the 
PropertiesChanged signal discussion: how do I make sure I'm not spamming the 
bus unnecessarily? Some applications may create and destroy objects often -- 
and properties may change A LOT more often -- so how do I know that someone is 
actually using these signals?
	
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20110228/a2a02b08/attachment.pgp>