Re: What would be a valid D-Bus interface name for a project without domain?

On Wednesday, 24 January 2018 07:23:49 PST Simon McVittie wrote:
> On Wed, 24 Jan 2018 at 06:50:42 -0800, Thiago Macieira wrote:
> > local has special meaning in D-Bus too (at least in QtDBus) in that
> > interfaces starting with "local." are not cached and are allowed to differ
> > between two implementations. That is, local.foo find in service A can have
> > different methods from local.foo found in service B.
> 
> This is the first time I've heard of this behaviour. If this is something
> that is meant to be standardized, please could you propose a patch for the
> D-Bus Specification?

It's something I wrote 12 years ago, mostly because I was involved in the 
early drafts for mDNS and still remembered that detail. I'm not sure it bears 
proposing to D-Bus as a whole, it's more of a QtDBus internal detail that it 
caches the introspections it found, except for local.*.

I also needed it because as part of the transition from DCOP, I needed to 
export the contents of random classes registered with the connection. So I 
needed to generate an DNS-reversed identifier that could be different from app 
to app. See https://code.woboq.org/qt5/qtbase/src/dbus/qdbusmisc.cpp.html#92

> What is QtDBus caching here? Is it the result of introspection,
> or something else? If services A and B both implement interface
> com.example.Foo, service A implements version 1.0 of that interface,
> and service B implements version 1.1 (with more methods, signals or
> properties, but backwards compatible with version 1.0), would a QtDBus
> client that interacts with service A before service B fail to use
> the newer features of version 1.1 in its interaction with service B?
> That sounds bad...

It's caching the meta object created by decoding the introspection. But what 
you described does happen: if your client reaches first the 1.0 service, it 
will cache the 1.0 details and reuse it for service B. The consequence is the 
inability to use the 1.1 methods, properties and signals via the Qt meta 
object system. They are still available via the raw QtDBus API, though.

In any case, depending on runtime introspection is usually bad coding 
practice. Developers should generate code using qdbusxml2cpp at build time. 
Obviously, it will represent one version only: the one that the application is 
designed to work with. It makes no sense to make calls to methods the 
application wasn't designed to recognise or receive signals it doesn't know 
what to do with.

It can of course call a method that says "this is version 1.0" and then adjust 
its behaviour accordingly.

> All the implementations that I'm more familiar with either record
> the signatures of methods at compile-time (GDBus gdbus-codegen,
> dbus-glib dbus-binding-tool) or when their compiled or interpreted source
> code is written (libdbus, sd-bus, GDBus lower-level APIs, dbus-python with
> explicit signatures), or cache the result of introspection separately
> for each (bus name, object path) pair (dbus-python with guessed
> signatures, which is a problematic design but is constrained by
> backwards-compatibility to stay the way it is now).

Caching the meta object was a performance optimisation, since early QtDBus 
code back in 2006 used to spend a lot of time in the XML parser and meta 
object generator. There was also no discussion at the time of interface 
versioning yet. It was mostly against wildly different interfaces exported by 
two different applications, so it forced developers to actually agree with 
each other.

But, like I said, the proper solution to this is to *not* do runtime 
introspection.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus