On 02/02/15 10:22, Dimitri John Ledkov wrote: > I would like to experiment with a user-bus, potentially in a transient > manner to have 3 buses: system, user, session busses.
I still think it's a bad idea to have both a user bus and a session bus. Having things "on the wrong bus" is definitely an API break, and having processes' messages be out-of-order will break application expectations (message order is guaranteed to be a consistent "total ordering" within one bus, but you can't even rely on "causal ordering" across multiple buses). > E.g. when org.freedesktop.Telepathy / ca.desrt.dconf moves to user > bus, things should know how to start talking to Telepathy/dconf over > user bus. If you have both buses, this is a flag-day API break for each thing that moves. Please don't go there if you want to reach a user bus in a finite time. If you only have a session bus, where "session" is taken to mean either login session or user-session/super-session depending on a choice made by the OS integrator and/or sysadmin, you don't get that problem. > I wonder if > this is at all an actual problem, maybe all current/sophisticated > dbus-heavy DEs cannot in fact have multiple graphical sessions for the > same UID, in which case switching to user bus today is non-regressing > (given that current active graphical session cannot migrate a seat (?! > not sure if this)). GNOME (at least, if you have the full GNOME suite including gdm) specifically does not support more than one graphical session per seat: if you are logged in (with screen locked) on tty7, and you type your username and password into a "Switch User" gdm prompt on tty8, gdm will just switch to tty7 and unlock your screen. I think this is a perfectly reasonable model. I don't know about multiple seats as the same user, but I suspect that, in practice, it doesn't work very well (if at all) and in any case, why would you? You are only physically in one place after all :-) I believe the situation last time we discussed this was that KDE does support more than one simultaneous graphical session, but Thiago was unsure whether that was by policy or coincidence. > Going down this rabbit-hole, the only difference between current > session-bus (e.g. where under gdm only one graphical login is allowed > per UID) and the user-bus seems to be the life-time of the bus (tied > from first login until last login V.S. X11 started and finished). Yes. This is part of the reasoning behind the mental model that Havoc proposed last time this was discussed: this is not about the D-Bus maintainers deciding how long a D-Bus bus lasts, but about OS integrators deciding how long a session lasts (or to put it another way, which of the multiple possible definitions of session should be the one used for D-Bus). When you think of it like that, the decision point becomes whether the OS integrator wants: * dbus-launch manages one session bus per X11 session (current reality, and apparently some people strongly prefer it this way) * dbus.socket/dbus.service manages one session bus per user-session/super-session (I anticipate that e.g. Fedora and GNOME-Continuous will probably make this simplification mandatory) * punt the decision to the sysadmin via whether an optional dbus-user-bus.deb, or RPM equivalent, is installed (I suspect I will have to support both ways for Debian for a while) Over time, as GUI things adjust to the 'systemd --user'-style model, I anticipate that the disadvantages of the user-session bus will decrease and its advantages will increase; maybe one day nobody will use dbus-launch and it can be deleted. S _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel