How to cope with restarted service?

[Havoc Pennington]

Hi,

dbus gives you a choice of a couple ways to deal with this. For most
services, you have two names:

* the well-known name like "org.foo.Bar" which is held by one process
at a time, but may be held by different processes over time
* the unique name, like ":1.122" which is never re-used by a different
process during the lifetime of the bus, and never changes for the same
process

("process" is a shorthand for a socket connection to the bus, for most
purposes each process has one connection.)

Depending on the API you're trying to use, you can use different patterns:

* if your API is completely stateless, you may as well just use
org.foo.Bar. In this case, what happens is that each message you send
may be going to a different process. That is OK if the API is
stateless. It's not OK if your API looks like:

  DoSomeKindOfSetupSuchAsRegistration()
  DoThingThatRequiresTheSetup()

or if the API returns handles of any kind to resources inside the
remote process. i.e. if one API call depends on state established by
earlier calls, then using the well-known name is dangerous because if
the service restarts your earlier calls have no longer been made.

* so if you have a stateful API, you probably want to watch the owner
of org.foo.Bar, then refer to that owner by the unique name, so you
are always talking to the same process. When the owner of org.foo.Bar
changes, you have to "start over" and re-establish your state. By
using the unique name like :1.122, you avoid inadvertently sending
setup calls to one process and later calls to a different process.

In both cases, you have to handle errors if you happen to make a call
to a process that's gone away.

Havoc