On Fri 20 of Jan 2012 17:37:43 Zane Bitter wrote:
On 20/01/12 15:30, Radek Novacek wrote:
> On Wed 18 of Jan 2012 18:34:14 Zane Bitter wrote:
>> Hi Radek,
>> I have one question about the D-Bus to QMF bridge: at the moment it
>> looks like there is one bridge object exported and that method calls
>> have to specify the object explicitly. Have you considered a model where
>> there are more, finer-grained objects? The ideal would be if we could
>> export every D-Bus object as a QMF object, but it may be that there are
>> just too many objects for this to be practical. My concern is that we
>> could end up missing out on a lot of the introspection capabilities that
>> QMF provides.
>
> You're right. This needs to be added, but I'm not sure what solution is
> the
> best. The simplest would be just to add methods to list all objects on
> DBus
> bus, then all object paths on given object. Can you (or anyone else) think
> of some solution to integrate this better with QMF?
(For those who, like me, are uninitiated in the ways of D-Bus, this
tutorial appears to be a useful resource:
http://dbus.freedesktop.org/doc/dbus-tutorial.html)
Easy ones first: I think we should surface each bus-name as a separate
QMF object.
From here on it gets tricky. The logical mapping to a QMF Class is a
D-Bus Interface. I'm guessing it's infeasible to expose every Interface
of every Object as a separate QMF object. One way around that might be
to not create QMF objects until the user requests proxies to be created
for a particular subset of the bus. It might be for the full bus-name, a
particular object path, or just a specific interface on a particular
object path. Without any knowledge of the subject, at the object level
sounds like about the right degree of granularity to me.
So, as you describe, there would be a way to list all of the object
paths, plus a way to create QMF proxies for all the interfaces on a
given object. The interface objects themselves could have proper QMF
method calls with parameter names and (presumably?) types defined. I'm
imagining a similar story for signals.
That's one idea. I'd be very interested in getting input from somebody
more familiar with the D-Bus side of the equation than I.
thanks,
Zane.
So, is following API agreeable?
DBusBridge object, will be started automatically when agent starts:
list_dbus_objects() -> [list]
- list of all dbus objects on system bus
list_object_paths(dbus_object) -> [list]
- list of all object paths for given dbus object
list_interfaces(dbus_object, object_path) -> [list]
- list of all interfaces for given dbus object and object path
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'
------
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...
Radek
[1]
https://github.com/rnovacek/matahari/tree/dbus-bridge/src/dbus-bridge