Proposing ObjectManager interface

[Thiago Macieira]

Em segunda-feira, 28 de fevereiro de 2011, às 15:40:28, Simon McVittie 
escreveu:
> On Mon, 28 Feb 2011 at 16:04:53 +0100, Thiago Macieira 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.
> 
> I endorse this general principle. (Telepathy has a very small version of it,
> which is that we list optional interfaces in an 'as' (string-array)
> property on each of our "class-like" interfaces.)
> 
> However, I also think application code should never need to list the
> methods, signals, properties in an interface, except in debugging tools
> like d-feet - if you're interacting with a D-Bus interface, you should
> already know what its methods, signals and properties mean.

Ok, then I withdraw my argument.

If you're supposed to know what the interface is and does before you create 
the proxy objects, then I think parsing XML for the corner cases where people 
don't isn't going to be a problem.

I've made this argument in the past though and sometimes I've been given the 
answer that the interface name is encoded in a configuration file somewhere, 
which contains the description of a call to be made.

I'd say that if that's your case, you can drop down to low-level interfaces.

> I'd be prepared to consider qdbus/gdbus/dbus-send to be in the same category
> as d-feet, although having said that, dbus-send and gdbus require you to be
> explicit about types anyway (and I think that's good).

qdbus guesses the target type given the introspection. This is not reflected in 
the API, nor is it all-powerful (you can't make calls to methods that contain 
dictionaries, structures or variants). qdbus was written with one purpose in 
mind, which was to replace the old "dcop" command-line tool, which also knew 
only a handful of types to send.

> > 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.
> 
> dbus-glib has the same restriction as QtDBus - the interfaces present on an
> exported GObject are (conceptually) part of the GObjectClass, so they can
> never change (indeed, they can't be different between instances of a
> class).

Actually, I spoke too soon. With QtDBus, each D-Bus interface is tied to one 
special QObject called an "adaptor" and that cannot change at runtime. 
However, you can add and remove adaptors as you please, so you can add and 
remove interfaces.

> However, in Telepathy we make a distinction between the interfaces present
> in the C code, and the interfaces "advertised" on D-Bus. For instance, our
> XMPP implementation can only provide new mail notifications on servers with
> Google Talk's XMPP extension (and you can't tell whether the server has
> that extension until you've finished connecting to it).
> 
> We deal with that as follows: in our Introspect() output (and our dbus-glib
> code), every connection produced by our XMPP implementation has the
> MailNotification interface, but the Interfaces string-array property only
> lists that interface when (a) connecting has progressed far enough to tell
> whether this server has the feature, and (b) it does have the feature.

That's good.

But my question was whether there was a need to be notified of its appearance 
and/or disappearance in a generic way. Another way of testing whether an 
interface is present is to just use it. If the call fails, it's not present.

I can see this as a problem only in cases where the call has side-effects and 
the workaround requires some extra activity (like polling for a file change 
instead of being notified by the kernel).
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20110228/1743c6ae/attachment-0001.pgp>