Fair points, some thinking out loud. Examples where you want dbus-daemon and X server to go together === Say the session manager has a "logging out now, please save files" signal. You want everything on the X server to get that signal. Or say you have a "suppress screensaver" API. You need every app on the X server to be using the same one of those. Or basically everything in gnome-settings-daemon (theme, font, etc.) has to be singleton to the X server. Shared NFS, separate sessions as same user === One thing I'm assuming is that there's a shared NFS homedir. If you are running as a different *user* on the remote system, then the right thing may be to have a separate session on that remote system. Two sessions on one X server is kind of a mess and hard to make work right, but if you're going to say it's allowed, then yeah it's two different dbus-daemon. I guess it's logical that if you can have two sessions for *different* users sharing an X server, then two sessions for the *same* user has to work also. A difference here is that if we prohibit two sessions for the *same* user sharing an X server, then we can say that each dbus-daemon on the same X server will have its own separate home directory. Which is at least something. Gconf === > 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. Right, but this is just because gconf/CORBA are fucked up and not using dbus (you can, btw, enable tcp for orbit... not that it's advisable). If we weren't dealing with some nest of legacy corba crap, then what we'd want is that ssh -Y launched apps *do* use the original config daemon on the original machine - using dbus to locate that daemon and talk to it. I'm OK with hacks to fix the legacy stuff, but not if they break doing it right eventually... so I think first you want the right way to work (that in fact you could share the config daemon for your whole session) and then second try to figure out some hack for this old gconf junk. Firefox === > 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. But sometimes what you want is that your existing firefox instance is used. Especially if the homedir is shared; then I can download the tarball from either machine and it's fine. But say I'm running email on one machine and firefox on the other, when I click a link in my email for it to do the right thing it has to open in firefox on the firefox machine. Recent files === > 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. Unless you have an NFS home directory, in which case a recent files service being global to everything on the X server is correct. Possible direction 1 === Concept: every app has to be in some session, but sessions can share an X server * A session can be for the same user or a separate user. * Everything in a session must have the same homedir, dbus-daemon, and X server. * Multiple sessions can share an X server. * We try to keep only 1 session per home directory on each X server, though this is not strictly required * everything on a dbus-daemon can assume it shares homedir and X server with everything else on that daemon * There is some way to create a session on a remote system, and tell the remote app how to join it (probably by setting DISPLAY and DBUS_SESSION_BUS_ADDRESS) * ssh default is to have the remote app join the existing session or error out "No session available; to create one, run xyz then run the app again using abc env variables" OR ssh default is to autolaunch a session in such a way that everything else on that machine will find it * some session on the X server has to "claim" all the singleton X server stuff such as: screensaver; settings-daemon; other sessions probably have to communicate with this session via X server (in fact using dbus for these X-specific functions probably becomes broken) * some session on the X server has to own login/logout ("uber session" "owner session" "master session"?) * the owning session has to tell the others when logout is happening, etc. ... probably using dbus becomes wrong, we have to use X Possible direction 2 === Concept: every app on an X server must be in the same session * A session can have multiple homedirs and users in it * dbus-daemon singletons can't assume everything in the session shares the same homedir, only that they share the same dbus-daemon and X server; however, they can assume no other daemons or sessions are using the X server. * in this direction, screensaver, settings-daemon, logout notification, etc. can be done with dbus, because we know there aren't other things using the X server on a different dbus daemon. While in the multi-sessions-per-X-server case, we really ought to throw all these things off dbus, or at least tunnel them through X. * if you "su" in this direction, then the su'd app is basically running with the original users' stuff (settings, etc.) but not the original user's home directory. Same for running an app on a remote machine. * A behavior here might be, you read root's email as root in a root-owned email app, but clicking links opens in your regular-user firefox rather than launching a firefox for root. * this direction is more like the historical behavior - if you have X resources for configuration, for example, they would be used by all apps from any user, on the same X server. Or if you use an X-associated networked audio server. This approach is the "traditional" way X was intended to work a long time ago, I think. Bottom line === I tend to think that either of these directions could work, and that right now the reality doesn't match either one, and the reality doesn't really quite work. Which one is easier to get to from current reality? Which one is most useful to get to? I don't know. Seems like to really untangle the mess here someone has to select and document one of these approaches (or some other coherent approach), and then start fixing the code that isn't compatible with the approach... In direction 1 for example, all those settings-daemon, screensaver, session manager, etc. thingies that assume they are the only user of the X server have to be fixed, and some communication among sessions sharing an X server is missing. In direction 2, the ssh forwarding is missing, and there are lots of bugs with people assuming two apps in a session share a homedir. A direction 3 could be that we make *no* guarantees; apps have to assume they don't share a homedir with other stuff on the bus (as in direction 2), *and* there are other sessions and buses sharing the X server (as in direction 1). That sounds great except I'm not sure it's actually possible to implement a desktop environment or suite of apps that doesn't make any of those assumptions. Maybe it is.