User bus conclusion

[Matthew Johnson]

I'm replying to several messages at once, apologies if it's a long reply, but
there are several related points which I'd like to make and I feel quite
strongly about, so I hope you can bear with me.

On Wed Nov 10 00:48, Lennart Poettering wrote:
> On Tue, 09.11.10 23:23, Matthew Johnson (dbus at matthew.ath.cx) wrote:
> > Sorry, I'm I misreading this? Or have you just suggested that we stop
> > supporting one user having multiple logins? 
> 
> Multiple logins will continue to be supported. But only one of them will
> be graphical. 

> ...

> Also note that you can still have as many X screens as you wish,
> however, only one of them is actually associated to your session. If you
> want more than one X screen attached to your session then consider using
> something like Xinerama.

These two statements seem at odds with each other? Can you have multiple
graphical logins per-user or not?

> > I think that's a completely untenable position to take.
> 
> Well, we disagree. In fact gdm on most distros doesn't allow you to
> login graphically more than once already.
> 
> Most desktop environments already fail in various ways if you login
> twice. Metacity probably still mostly works, but everything beyond that
> (gnome-panel!) will fail miserably sooner or later. Firefox actively
> blocks you from being started twice by the the user with the same $HOME.
 
You seem to be under the misapprehension that everyone uses GNOME, everyone is
a local user logging in to the physical machine and noone wants to use more
features than windows. This is, sadly, a common view.

While it is true that we wish to make the above experience as easy as possible
to appeal to users for whom that is their mode of operation and whose only
computing experience is Windows or Apple, it is not true of everyone.

Thiago has already made the point that KDE works fine in that mode. I don't
know about XFCE, but I would not be surprised if it did. Personally, I use
xmonad, which has no problems with that whatsoever and I know many people who
use other such lightweight session/window managers all of which have no problem
with multiple simultaneous sessions.

You may argue that these things don't use DBus - perhaps that DBus is designed
for an integrated desktop. I think this is the wrong view to take, however.
DBus was designed in an era where the two major desktop environments used
different IPC protocols and hence there was no integration between applications
written for one system and those written for the other. With DBus now, we have
a single IPC protocol which is used for both.

It would be very short sighted, however, to then exclude other session
managers.  Then you have a state where applications will work with both KDE and
GNOME - but not anything else. DBus is about interoperability, regardless of
the system that people are using.

On Wed Nov 10 03:52, Ryan Lortie wrote:
> On Wed, 2010-11-10 at 08:56 +0100, Thiago Macieira wrote:
> > I'll probably ask that the session bus be left as it is: continues to get 
> > started, no repurposing, no deprecation warnings.
> 
> This is the compromise position I mentioned.  Allow desktops that decide
> that only one graphical session per user is allowed to use just the USER
> bus.  Allow desktops who want the possibility of multiple sessions per
> user to use a USER bus plus a SESSION bus.

Subsequent messages like this have somewhat alleviated my fears. This is, IMO
the correct approach to take - however, I have a note of caution to add.

Desktops are not closed environments, I don't run GNOME - and yet I run GNOME
applications; and KDE applications. If we say "Oh, GNOME will only ever support
one, therefore all GNOME applications will just use the USER bus" then those
applications will break when run in a session manager that does allow multiple
sessions per user. This is a dangerous route to take, since again it restricts
what people can do, which applications run where.

At the moment DBus is not well provided for a selection of use cases. Multiple
graphical logins do work, but there is no association between buses from the
same user, even where that is desirable. There are also issues with what to do
with X forwarding over SSH and so on.

The USER bus I see as an answer to enable these use cases, not prevent them. If
sessions are restricted to one per user then what advantage does the USER bus
have? It is equivelant to the SESSION bus.

On the contrary, if we introduce both busses, with strong conventions about
which bus is used for what, then several interesting use cases are enabled.

 - notification applets can listen on the USER bus, so that messages get
	displayed on all sessions
 - cron jobs can send notifications to the USER bus for the above
 - ssh agents, gconfd, etc ("headless" user services) can be singletons on the
	USER bus and their services be available to all sessions
 - graphical applications can be singletons on the SESSION bus, calls to them
	to open windows (browsers, etc) will remain within the correct session.

This would be a change which enables people and not restricts them - one that I
would thoroughly support.

On Wed Nov 10 03:55, Ryan Lortie wrote:
> On Wed, 2010-11-10 at 08:49 +0100, Thiago Macieira wrote:
> > However, this introduces a minor surprise factor: if you have an X session 
> > running and then remotely ssh in (without -X), running X apps will not result 
> > in an error. These apps will simply run and show on the screen you're not 
> > seeing.
> 
> I didn't consider this. :)
> 
> I think this will clearly confuse anybody who is used to how UNIX
> currently works.  It's actually the right thing, though (from the
> standpoint of "why shouldn't it work?").

I'm not convinced it is the right thing - starting an application on a screen
200 miles away that you can't access doesn't seem like it to me.  More to the
point, there are several issues around here which I don't as yet understand how
they would work in the 'only a user bus' world.

Firstly, what if they _do_ ssh with -X (or -Y) and try and start a graphical
application. (for clarity, a user logs in from machine Alpha to machine Beta
with X forwarding) Would the application display on Alpha or Beta? Would half
of the application appear on each? Would the application display on Alpha, but
if it needed to call another application would that start on Beta?

The second one is what if I have many machines with NIS and NFS home
directories. Does this work when they all use the same path on the same NFS
share for their USER busses? Can I log into more than one machine at once?

These are work flows I use every day. Having DBus-aware applications fail in
either of them is not really acceptible.

Fundamentally, we should look at what DBus is there to do. I believe it is
meant to be a universal IPC system - usable by any application, allowing any
application to be used with any desktop environment or session manager. Yes,
there are some things it's not designed for - RPC busses that span machines,
for example, but this latest proposal is restricting use cases I believe we
should support.

Not only that, but as Havoc said, we are coopting decisions that are not
rightly ours to make, in order to make our lives slightly simpler. DBus
is about enabling use cases, not about restricting them.

I hope you all took the time to read this far and thank you for doing so.

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20101110/e903cb60/attachment.pgp>