On 24/01/12 16:55, Radek Novacek wrote:
So, is following API agreeable?
DBusBridge object, will be started automatically when agent starts:
Yep.
list_dbus_objects() -> [list]
- list of all dbus objects on system bus
How long is this list likely to be? Do we need some way of filtering it?
list_object_paths(dbus_object) -> [list]
- list of all object paths for given dbus object
I'm confused by this; is there another way of identifying objects than
by path? My understanding was that objects and paths are 1:1 and that a
path is the only way of addressing an object.
list_interfaces(dbus_object, object_path) -> [list]
- list of all interfaces for given dbus object and object path
This may or may not be required depending on how the rest is done. It
can't hurt to have it, I guess.
Now there are two possible options:
1)
add_dbus_object(dbus_object, object_path)
- creates separate QMF class that will match given dbus object and object
path. Interface will be encoded into method/signal/property name like:
'org.matahariproject.Host.reboot'
So there will be all interfaces for the object and path mixed together with
interface prefix
2)
add_dbus_object(dbus_object, object_path, interface)
- in this case methods/properties/signals will be named simply: 'reboot'
I'm a fan of the simpler method/property/signal names, since some people
will be using this from the shell. It would also mean we could reuse the
same QMF class when multiple objects implement the same interface. The
object path would then be accessible as a property (one possible problem
with that: avoiding a name collision).
We could reserve a separate namespace for D-Bus interfaces, so e.g. the
Matahari Host D-Bus agent's object would show up at
"dbus.org.matahariproject:Host". That's probably an unfortunate
example... the Introspectable interface, say, would show up at
"dbus.org.freedesktop:Introspectable" in QMF.
My initial thought was that you wouldn't specify the interface in the
add_dbus_object() call, and it will just create every interface at that
object path. Unless there are likely to be large numbers of interfaces
for each object?
------
The case #1 is already done in my repo on github [1], I didn't try #2 so there
might be some technical difficulties.
In both cases the resulting QMF class will be "full featured": method with
types, signals, properties...
Cool :)
cheers,
Zane.