Plugin-based auth/transport (WAS: SSH transport)

[Havoc Pennington]

Thiago Macieira wrote:
> There's also a very strong reason not to do it: many applications are not 
> prepared to the fact that their peers aren't on the same machine.
> 
> I know many KDE applications that happily exchange file paths. To the 
> point, the whole KDE file watching mechanism (KDirWatch) was ported to 
> D-Bus and sends file paths back and forth. This will break if remote 
> applications are to use the local D-Bus indiscriminately.
> 

I think the model is just too complicated if one DISPLAY can be 
associated with a sort of poorly-defined set of several session bus 
daemons. The reason I'd really like to do dbus the same as X is that 
then we have *one* way that things work and anytime we solve a problem 
for X we solve it for dbus and vice versa.

Also, the dir watch case is just one example; the reality is that it 
varies by the example whether you want to scope the service 
per-(session,machine) instead of per-session. The file path case would 
benefit from per-(session,machine), but take another example like a 
clipboard service or a screensaver, and those examples need to be 
per-session, regardless of how many machines are involved.

So the dbus design is to pick the *broadest* reasonable scope for the 
bus daemon (per-user would be broader, but not reasonable due to 
implementation problems and it being the wrong default almost always). 
Then, if a particular service needs a narrower scope, it is supposed to 
narrow the scope itself using either the bus name or details of its API.

For example, the dir watch service could be per-machine by including the 
machine uuid in its bus name. Like org.kde.DirWatch.uuid-goes-here

Or it could also use a hostname in its API somehow, like:
  WatchFile(in string hostname, in string filename)

There are some problems with this still, such as how the dir watch for 
the remote machine gets launched, but at least it will give a clean 
error instead of watching the wrong files. And there are probably ways 
to solve the problems.

To summarize, why I think the bus scope is per-session (corresponding 
exactly with the scope of the X server):

  - it is simpler to understand and implement if it works exactly the
    same as X
  - per-session will be the right default for many services at least
  - it is easier for bus names or APIs to narrow the scope by including
    extra bus name components or method args, than for a service to
    broaden scope by connecting to multiple bus daemons (or something...)
  - I've always said it's per-session on this list, and the API is named
    as if it is, so it's nice to stick with that expectation

Havoc