On Tue 24 of Jan 2012 18:09:11 Zane Bitter wrote:
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?
I have 14 services currently running on system bus. But there is also DBus
activation that we must take into account. One might need to call some object
even when it is not started, so this should be listed too. For my system,
/usr/share/dbus-1/system-services/* says 36 items (one entry should be one
object with DBus activation). So some filtering might be useful.
> 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.
I think that both dbus object and object path must be specified to identify
the object unambiguously.
> 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).
I agree, this variant is nicer to use for user. I'll try to implement it to
see if there aren't any technical difficulties with this approach.
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?
There are usually 'org.freedesktop.DBus.Introspectable' and
'org.freedesktop.DBus.Properties' interfaces, so we might need to blacklist
these (properties can be accessed trough QMF properties so no need for them;
the introspection can be worked around by QMF introspection of the object).
Except of those two there are usually one or two other interfaces, so no
problem to create QMF object for all of them.
Or the interface argument can be optional and it'll create all objects if not
present.
> ------
>
> 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 :)
> Radek
>
> [1]
https://github.com/rnovacek/matahari/tree/dbus-bridge/src/dbus-bridge
cheers,
Zane.
Thanks for your comments.
Radek