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

[Simon McVittie]

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?

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...

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).

    smcv