On 25/01/12 09:24, Radek Novacek wrote:
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.
As far as I can tell there is only one way to refer to an object within
a particular message bus, and that is by path. The code you have already
written seems to be consistent with that.
There are, however, multiple ways to refer to a message bus: each has a
unique name (like ":34-907"), and may have one or more well-known names.
>> 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.
I like that idea a lot.
>> ------
>>
>> 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
Sounds like we are basically on the same page. Thanks for all your work
on this :)
cheers,
Zane.