Comment 34 for bug 328575

(In reply to comment #21)
>
> There are two ways I can think of to keep it from breaking:
> * add a dbus transport that tunnels over X protocol
> * have ssh and su forward the dbus connection also
>
> Anything else simply will break. Having two sessions connected to the same X
> server is not tractable for app developers and gnome developers to get right.
> There's no coherent semantic to it, since supposedly single-instance things
> become unpredictably multi-instance, and portions of the desktop you want to
> talk to become impossible to contact.

Keep in mind unintended consequences.

Let's say hypothetically that Firefox (correctly) grabbed a name on the session bus for uniqueness instead of using the X server as it does now.

If we turned on DBus forwarding over ssh when you specified -Y, then that would *break* the Firefox use case, because Firefox would now see the name on the session bus on the other machine, and just open the URL there and exit. Thus, the sysadmin couldn't download that tarball of mediawiki they were trying to.

Here's another one - we recently changed GConf to use DBus to lookup the IOR for various reasons. If we started forwarding the session bus, then all of a sudden "ssh -Y" launched apps would try to look up that IOR (something in /tmp) and *fail*, because obviously the CORBA socket is on a different machine.

I understand your original design was that the session bus matched the X server, but as I said before I've come to the perspective that there's a huge difference between X and DBus.

Namely, X is a display system. Everything around it is focused on display. Not that other things aren't wedged into it, but still. DBus on the other hand is for *entirely arbitrary* things. Preferences, power management, networking, etc. If we change how the DBus scoping works it affects everything. All DBus services have to be evaluated for behavior in this case.

A very common problem in all of these is going to be services which have an implicit dependency on a shared filesystem as well, as in the GConf case. Think for example of a "recent files" service which has a method like org.freedesktop.Recent.GetRecent(). Obviously that's going to be in terms of local files, which anything remote can't access.

So going back to the 3 key things:

1) X server
2) DBus
3) Filesystem (really kernel, let's skip the NFS insanity for the moment)

2) and 3) are both essentially arbitrary protocols where anything can happen. 1) has always been about display.

So my argument again is that the least confusing thing is that 1) is can vary, and 2) and 3) should come together.

The reason we don't just put the dbus socket as $HOME/.dbus to enforce this is simply to avoid breaking outright on NFS. But NFS is an application problem, not something DBus can solve.