Add support for deep introspection

[leogermond]

This commit adds support for a deep object introspection; it means that any child object that is described with a node tag, will be introspected as well, recursively.
This way a whole hierarchy of objects can be introspected in a single get() call.

The children are then added to the nodes dictionnary attribute.

Typical use case is:

from pydbus import SystemBus
s = SystemBus()
bluez = s.get('org.bluez')
bluez.nodes[bluez.nodes.keys()[0]].StartDiscovery()

Instead of the more complicated:

from pydbus import SystemBus
from xml.etree import ElementTree
s = SystemBus()
bluez = s.get('org.bluez')
et = ElementTree.fromstring(bluez.Introspect())
nodes = {n: s.get('org.bluez', '/org/bluez/' + n) for n in [
    e.attrib['name'] for e in et if e.tag == 'node' ] }
nodes[bluez.nodes.keys()[0]].StartDiscovery()

[ukBaz]

On BlueZ if I want to get all of the objects I get it by:

from pydbus import SystemBus
bus = SystemBus()
mngr = bus.get('org.bluez', '/')
mngr_objs = mngr.GetManagedObjects()

This returns a dictionary of all the items. Is this doing the same at your deep object introspection?

[leogermond]

Ho ok; I did not know how to access GetManagedObjects so that's great. Introspection and ObjectManager are two different way of doing that kind of stuff but ObjectManager is actually the one used by Bluez and it's more versatile. Thanks for the tip 👍

[hcoin]

Apropos, take a look at https://github.com/hcoin/pydbus/wiki
There is defined an entire translation infrastructure that moves dbus closer to what than how.
Named variables, introspection including when python to dbus that has a 'v', etc.

[leogermond]

That's neat, it seems to be convergent with the efforts I'm making to build open IoT devices that "just work".

[hcoin]

I'm hoping those who publish dbus services, or those who care about dbus services use in python, will maintain the translation dictionaries necessary. The whole point is to remove from the python dbus user the obligation to keep track of which variable goes in what position, glue code to create 'call by reference', all the engine room stuff. I've just uploaded the bulk of the code that implements all that. I'm testing the rewrite logic for when dbus service publishers include a 'v' so the python code writers do not have to cope with any glib 'variant' logic. Once that passes unit tests, it will be testing the named variable glue and then .. that's it. All the '0 means off' and '1 means cold' an '2 means hot' and 0x40 means flag x and 0x20 means flag y is done. Basically everything to do with variables passed by argument position is done. All the docs are done.

[hcoin]

I like that IoT concept you mention. The problem I'm aiming to solve is 'deprecation' and change in dbus specs. So many 'little changes' happen that sooner or later Iot code in the field needs to be 'updated' to 'keep up with where it was'. Now, the translation dictionary writer can ADD variables to dbus calls to include version numbers or defaults for programs that are 'old' that don't provide the necessary. That way, code stays compatible without change and only the folks that want the value of the new thing need to cope with it.

[hcoin]

And.. the code I've uploaded is 100% backward compatible will all current pydbus uses.