> In general, this kind of thing is always going to be broken in some way.

Agreed; the bottom line for me though is that we don't want to run around in circles. It's just like the old X clipboards stuff; app A worked around app B and app B worked around A at the same time, and then they were both broken again, and had to toggle back to work around the other, and then they were both broken again...

So if there's a tradeoff where scenario such-and-such works and some other one does not, there should be a document that just says: we've agreed to change ssh, X, dbus, distribution defaults, gconfd, apps, session manager, settings daemon, etc. to support such-and-such, and this other scenario abc we've agreed to not care about.

And then when the bug reports come in for abc that's been traded off and punted, we can just point to the writeup document and WONTFIX because we want to keep the such-and-such scenario working and that requires that abc does not work.

> I think the focus
> should be on compatibility (don't break what worked before like "ssh -Y server
> firefox" to download stuff on the server), and flexibility (let apps make
> choices).

"ssh -Y server firefox" more just happens to work ... it isn't really defined _why_ it works and what the desktop has to do to make it keep working. Picking the "why" for how it keeps working is what will determine which other scenarios work or break. In the short term, ssh -Y server firefox can probably keep working regardless, the question is what else breaks given the "why", or which desktop features firefox might start to rely on that might break "ssh -Y server firefox" inadvertently... gconf being a great example.

> * Not a big fan of requiring a rootless X server; admittedly in reality for
> the next 10+ years we'll need X on the free desktop, there does exist a
> wayland future ideally

Wayland could theoretically design-in a solution, who knows. The possible win of rootless X is that you could avoid any tricky stuff for apps to get right, and keep the app-visible model very simple (and virtualization-compatible...).
A second X server, whether nested or rootless, or VNC for that matter, is the direct analog of opening a new terminal session on a remote server. Opening just one app on an existing X session is kind of like running something on a remote server and having it be a job in your local shell. If that melts your mind, that's the problem created by letting "ssh -Y server firefox" work.

The big appeal I think is to be able to solve one problem (a nice way to open a nested display or VM) instead of fixing N apps.


Anyway, to stay on topic for dbus, re-reading the original bug topic...

You said only this can be expected to work reliably:
1 user id <-> 1 login session <-> 1 dbus-daemon instance <-> 1 X server

And I think that is pretty much the de facto situation, that's all that's going to work all the time without screwing around, because there's no agreed-upon way that anything else does work or doesn't. There's some real spec work and thinking to be done about other situations that could work. I think maybe they could, and maybe there are related dbus changes, but who knows what those changes are until someone documents how it all should work.

With dbus right now, 'ssh -Y server firefox' actually does work, doesn't it? I would expect it probably happens to work due to autolaunch, and not using any desktop services that assume they share an X server with the app (such as a screensaver inhibitor or single-instance app that really needs to be single-instance).

My take on the original bug is that "su -" instead of just "su" should be used; inappropriate env variables are getting forwarded. Then autolaunch will kick in and things should work fine.

I'm pretty uncomfortable autolaunching on a *bad* DBUS_SESSION_BUS_ADDRESS. The user set that address, whether accidentally or not; if it's broken there should be an error message, not silent launch of the wrong bus.

The "put uid in address" solution breaks the case where someone actually does want another user on their bus, which may (or may not) turn out to be a case we decide should work.

So I'd say the bottom line right now is: we kinda need that documentation of what will be supported and what won't, and in general how all the stuff (session-specific daemons, X-server-specific daemons, apps, dbus) is supposed to work together. I don't know that dbus bugzilla is the right forum to propose the answer on this. But once there's a document, we could come back here and implement the dbus portion of the answer.

In the meantime, I think the workaround is to unset the env var, for example using "su -" ... don't see much alternative.