well-known names note

[Havoc Pennington]

Hi,

I was just reading
http://lkml.iu.edu/hypermail/linux/kernel/1504.1/04662.html and wanted
to toss Greg a note about:

"There are many applications out there which don't address messages to
their well-known name destination but to the ID which they looked up
earlier and cached. In fact, that behavior is the default in the gdbus
library implementation."

You guys may have decided now that this is a bad idea, but I wanted to
be sure it's clear why it was designed this way originally.

The reason is that dbus views the world in a stateful way assuming
that connections, and name ownership, can be tracked reliably. This is
different from say http, and it's one reason that people used to
Internet-oriented protocols find dbus strange.

In a world of state and reliability, we can write code where later
requests make assumptions about state established via earlier
requests. That is, we can have psuedocode like this:

  myId = RegisterMyself(uniqueName)
  assert(IdIsRegistered(uniqueName, myId))

You cannot write code like this if you're using the well-known name
instead of the unique name, because the process you are talking to may
change between messages.

This guarantee makes apps a lot easier to write reliably, because it's
OK to have stateful protocols, as long as you handle the case where
the name owner changes.

The idea is that in resolving the well-known name to a unique name,
you are creating a logically stateful/reliable connection to a single
process. A library could make this look just like a dedicated socket
to the other process if it wanted to, including ordering of messages
and notification on socket close.

Regarding the specific lkml discussion, I think it would be
semantically bizarre to change permissions depending on the name
you're using for routing. The "correct" way to use dbus - at least
back in the day, maybe you all have changed it - is to resolve the
well-known name to a unique name and then use the unique name, thus
getting a logical "socket" to a specific process.

The hostname vs. IP address analogy sort of works, BUT imagine you are
reliably notified if the "hostname-IP" mapping changes so you can
reconnect, and you have a stateful connection (like websocket, not
like http). Unique names enable a "conversation" between two clients
to work like a stateful connection, while well-known names force them
to be stateless like http or udp.

As always, dbus is blatantly ripping off X11 protocol. The well-known
name is a "selection" and the unique name is a window ID. However,
explaining one obscure protocol in terms of another obscure protocol
is perhaps not helpful. :-)

If dbus didn't assume stateful/reliable, then desktop apps and the
desktop itself would have to be written more like a distributed system
and less like a single program that happens to contain multiple
processes. That would be a bad idea, because distributed systems are
hard as hell, and there's no reason to bite off a bunch of rocket
science when you don't have to.

X11 is perhaps the main precedent that shows the value of the dbus
model, if dbus itself isn't convincing. It's a stateful/reliable
hub-and-spoke design, and much of the stuff that seems "weird" vs.
other protocols is due to that.

Anyway sorry for the drive-by from the past. Thanks to all of you for
all this work on dbus!

Havoc