Re: GDBus/GVariant: well-known vs unique names

[Simon McVittie <simon mcvittie collabora co uk>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, 14 Oct 2009 at 21:34:26 -0400, David Zeuthen wrote:
>  - Ideally make insane things impossible to do
> 
>    - e.g. only allow proxy creation for unique bus names - not
>      well-known names. Instead people will discover they should
>      be using e.g. g_bus_watch_name().

I don't think using well-known names is insane; you just have to be a little
careful. Forbidding them would break automatic service-activation, which is
not only implemented but also explicitly mentioned in the D-Bus specification,
so clearly Havoc didn't think it was insane either...

In practice if you're using the well-known name on a proxy, then you want to
watch the name owner *as well* - the proxy could do this automatically?

The fundamental decision to make is whether your D-Bus API's assumptions would
break if you called a method on one instance of a service, the instance exited,
a new instance started, and you got a reply from the new instance. Most
complex APIs do break (they are stateful, using that word quite loosely), in
which case service-activation doesn't work and using the well-known name is
indeed insane. As a result, I do agree that the *default* should be to use the
unique name; this is the "safe option", and it's the default in dbus-python
too. (If you make a proxy for a well-known name with follow_name_owner_changes
disabled, as is the default, then dbus-python will try to start it for you.)

However, some APIs either work by coincidence (e.g. because they're so simple),
or are specifically designed to work like that (the new instance will closely
resemble the old one, and either doesn't need any of the old one's state, or
loads that state from disk on startup).

A prerequisite for having calls by well-known name work correctly is having
either a well-known object path as an entry point, or persistent object paths
that can be saved across service runs.

Most APIs that follow the "one service with one object implementing one
interface" pattern can be used with a well-known name, I suspect; for instance,
the Galago/freedesktop.org notification daemon API is mostly OK for this use.

I say "mostly" because in corner cases, like replacing your notification daemon
implementation with one that doesn't support markup, the API requires
capability discovery to be done again. However, if the notification daemon spec
was changed so that messages were *always* in GMarkup-style markup (and
text-only daemons were required to ignore/strip out the markup), then I think
it would be safe to use by well-known name: you could do capability
re-discovery opportunistically, in order to start or stop using advanced
optional features, but the message you sent to the old implementation would
still be perfectly valid for the new one due to the graceful fallback in n-d's
"hints" mechanism.

(I'm not suggesting changing the n-d spec; rather, I'm using a hypothetical
changed version of its spec as an example of a well-known-name-safe API that
would be quite easy to design.)

In Telepathy[1], you can safely use the well-known name for:

* AccountManager (well-known singleton)
* Account (persistent objects in the AccountManager with saved object-paths -
  you do need to handle the corner case where your account was deleted while
  the AccountManager wasn't running, but our domain-specific libraries do that)
* ChannelDispatcher (well-known singleton)
* ConnectionManager (well-known singleton per installed CM)
* Client (UIs, loggers etc. invoked by the ChannelDispatcher - well-known
  singleton per installed Client)

but you can't sensibly use it for:

* Connection (transient object in the CM, representing a connection to the
  server)
* Channel (transient object in the CM, representing a channel of communication)
* ChannelDispatchOperation (transient object in the ChannelDispatcher)
* ChannelRequest (transient object in the ChannelDispatcher)

In telepathy-qt4 we make this very explicit by having an abstract DBusProxy
class (loosely based on telepathy-glib), which concrete subclasses
StatefulDBusProxy and StatelessDBusProxy. Stateful and stateless aren't quite
the right words, but they're the best I could come up with at the time...

    Simon

[1] I think making it halfway through an email about D-Bus before I mention
Telepathy might be a first for me :-)
-----BEGIN PGP SIGNATURE-----

iQIVAwUBStcWH03o/ypjx8yQAQh37RAAhjJ0EupOIDDYy2LMPnVMMLJtj1P6tmAC
CIzhwL+gHWxGsFAAXgBIIk4lvt0af7SH1WuexIYb0ZgtCz5t8PGG+1b3FJeu7MNJ
F9POtjLuLrU8DaZRc4AifogA5xS32TEK0whOx9RSXAduZu3QQHWw1t9TIdU5HNgh
1Ky99PAPkfRneHhKhtOmDTXl4hG9/0v4oOMNH/rjf+jqWdUUP+/Svt4GWjtfTwFq
tuK9XM+MRaj3zVjYmby9v7RK/TlvYJv4oLYg999KYAjC2QtBaUnzIMDeIVFLf/2o
ay4Pvsmo9Dm9p2+NYc3J3Wi2OpO82tV3nDnMOmBn2RWrWqmlvgG5I/Z2VaqFXuWr
Arx7sYTJj7rmE9nBemYMLoiSB7DNN5DPHg8IPq5OuZ6QoyhjWlRXALj6gIwHN0Fj
HYbTG3OMfIK6WYoQf5YVOmS3/HjKULQt/0H0wdIXis2WF661HjOidqMIx4a94SDN
7KP3eB3kOuybkuNHCbpVIJ3mXp9SRKKrCxI7gJENAwSpbKiUlF0YdX83PU5WU881
zhMBombvVSd3ZgXRVXzMoMhmmDKLixUEMJJ64kIp7X8/JPNphkGukGc1fPWR0H2o
/Nbhy+s3k6YhUo0fSPtELfStfJCq06V+CPXegEUWBb1MWJlk90TwdM2ettqU7bCP
B7iLSrD1204=
=J0ZN
-----END PGP SIGNATURE-----