Proposing ObjectManager interface

[David Zeuthen]

Hey,

On Mon, Feb 28, 2011 at 10:04 AM, Thiago Macieira <thiago at kde.org> wrote:
> For one thing, I'd like to see something us use D-Bus for introspecting D-Bus,
> not have to fall back to XML, which is expensive to produce and/or store and
> then to parse. Having a standardised a{s(iv)} for describing an interface
> would do wonders:
>
>        DICT of STRING to (INT, VARIANT)
>
> where the key (string) is the element name, the INT is the element type
> (method, signal, property, annotation) and the variant contains the element
> description. We'll have to standardise on them too.
>
> I'd suggest that we use the ObjectManager interface for this, but I'd propose
> the following modifications:
>
>        GetAllMatch(in OBJECT_PATH root, in BOOLEAN recurse)
> Gets all elements that match a given path root element, and maybe recurse. A
> viewer tool like qdbus, qdbusviewer or d-feet would call
>        GetAllMatch("/", true)
> The return value would have to be the full description, for each object. So it
> needs to be a map of object paths to the object description ("a{o?}"). The
> value is the interface description I had above, thus making: a{oa{s(iv)}}.
>
>
> QtDBus doesn't allow adding or removing interfaces to an existing object
> today, but that's an internal limitation that could be lifted. I'm wondering
> however what's the interest in this. Do others rely on interfaces appearing
> and disappearing on existing objects? I've never seen this.

I'm planning to do this in udisks 2.0 [1] ... and I'd be happy if it
can easily work with QtDBus so Qt apps can use their native D-Bus
library to access udisks!

[1] : for example, an object implementing the BlockDevice interface
will implement the Filesystem interface only if the block device
actually looks like a mountable filesystem.. and this changes as you
run wipefs(8) and mkfs(8) on the device.

> I think determining object creation and destruction would be a lot more
> interesting.

I really don't want ObjectManager to be a replacement for enumerating
objects or the current Introspectable interfaces. I do echo your
concerns about the current Introspectable interface, but I really want
ObjectManager to be something that can be used 0, 1 or more times in
your app only where it's suitable (see my reply to Simon for various
guidance on when to use and not to use ObjectManager). For
introspectable, I would welcome work on making a nicer version of
Introspectable.Introspect() that doesn't require parsing XML because
I, for one, is certainly not a big fan of having to parse XML.

> I still have a question which has plagued me for the entire duration of the
> PropertiesChanged signal discussion: how do I make sure I'm not spamming the
> bus unnecessarily? Some applications may create and destroy objects often --
> and properties may change A LOT more often -- so how do I know that someone is
> actually using these signals?

My guess is that a lot of new GNOME code is using this since GDBus has
support for it and it's easy to use. All my new code is certainly
using it and udisks 2.0 will use it to a great extent. It will
actually create a lot less traffic since udisks 1.x current has an
empty Changed() signal that causes each client to call GetAll()... and
there's usually at least 2-3 clients per login session.. so...

Anyway, my answer to your question, I guess, is still the same as last
time this was discussing... I'd solve the problem by extending the
bus<->app protocol by negotiating a protocol feature during the
authentication whereby the bus would let the app know what match rules
it has that applies to the app (including when this set changes). Then
the D-Bus library for the app could be smart about not having to spam
the bus if the match doesn't match locally. I'm pretty sure something
like that would work and I don't see any apparent race conditions.
Does that make sense?

Either way, I think it's orthogonal to the ObjectManager interfaces
but, sure, the less traffic and wakeups we can generate, the better!

     David