per-user dbus

[Havoc Pennington]

Hi,

On Fri, Nov 13, 2009 at 11:30 AM, Colin Walters <walters at verbum.org> wrote:
>
> I wouldn't call it "Just Works" personally.   NFS and multiple
> sessions give you the Last One Wins behavior, which is a pretty quick
> path to data loss under any real-world usage besides "Oh look, I can
> log into the desktop twice!" demos.  Open an openoffice document on
> display/session A, go to another department/home, log in again on
> display B, try to access your document, make a quick modification
> forgetting you had it open in session A...
>

That's true but it's way better than what happened with bonobo,
gconfd, etc.  (i.e. total failure to work _at all_ - the complexity of
apps and daemons having to manually deal with multiple displays - i.e.
sessions - was totally over the top and they never were able to)

(If we want to set some UI policy I think it's somewhat fair game to
declare two X sessions for same user on same machine to be
Wrong/Useless, which means that multiple session buses only arises for
console/ssh - irrelevant for most apps - and for multiple machines.
This makes a (user,machine) bus even more useless. And the
"openoffice.org editing same document twice" problem is just not
solveable a across multiple machines, so I'd say just punt it.)

The bottom line is that 1 X server, 1 session, 1 user is a nice simple
model that apps get right; everything else is underspecified,
underdocumented, poorly understood, etc. App devs _might_ get it right
if there were clear guidelines, but as we can see on the "su" bug,
nobody has a frickin clue how this is supposed to work. And it _can't_
work in every case people can think of, all at once. Some of the cases
have to lose. Which means some decisions and some docs are required.
Or, we can leave the status quo which is basically, people don't try
to log in more than once if they're sensible ;-)

Havoc