D-Bus User Bus

[Lennart Poettering]

On Sun, 16.05.10 23:53, Rémi Denis-Courmont (remi at remlab.net) wrote:

> > - generally, we should emphasize sharing of data between sessions of the
> >   the same user. Ideally we'd even allow copy/paste between them.
> 
> I would disagree with that. If I open a video file in one session, I don't 
> want it played in an existing instance of a media player in another session. 
> Same goes for cut&paste.

Really. You think it would suck if you could login via ssh and copy
something from that terminal to your UI session on the same machine?
> 
> > - it is a simple fact that currently only a handful of gnome
> >   applications can safely be run on multiple graphical logins in
> >   parallel. IIRC kde's session manager actviely disallows multiple logins
> >   by the same user. Instead of miserably failing Gnome apps should be
> >   more explicit about this, too i guess.
> 
> Fix broken apps, or at least have them handle error casess properly.

Oh, you are so young!

> > - I think it is love's labor's lost to ask each and every UI program to
> >   be fixed for multiple parallel logins of the same user. Teaching every
> >   programmer about the intricacies just doesn't scale. Also the value
> >   is minimal, since all desktop environments support virtual desktops
> >   anyway.
> 
> It's going to be worse with only a user bus. Those applications that do work 
> today will break as they fail to namespace the bus names. In fact, there will 
> be an incenvitive not to do the $DISPLAY thing, to keep it simple for DBus 
> "clients".

Well, appending two strings is not really that hard is it?

> > - adding another bus complicates an already complex system where new
> >   users already have a hard time grasping the difference between the
> >   system and session bus
> 
> Your software has a more severe problem if your end user need to know what 
> DBus is.

Well, s/user/developer/.

> > - we already have a lot of services on the bus and moving them from one
> >   to the other won't be fun, if we want to keep compat.
> 
> On my desk, all of those services belong on the session bus.

Really? Then you are probably not running gconf, pa, geoclue, teleptahy,
rygel, the evolution data server, a keyring or anything like
that. (Translate that to the KDE counterparts)

> > - the current scheme does not care at all for SSH logins (or console
> >   logins).
> 
> Could be fixed.

Yes, I was proposing a fix.

> >   Nor does it cover cronjobs.
> 
> Nor does the user bus. You probably don't want all crontab users having their 
> bus lying around all the time, regardless of which is actually logged on. And 
> the main use case for cron is precisely to run things while not
> logged.

Well, I already mentioned that the bus would be refcounted by
logins... And refcounting the bus from the cronjob too is the next
obvious step I implied.

> > - currently, all out busses are per-machine, however the specs leave
> >   that open, so that busses could in theory be redfined to be
> >   network transparent in case of NFS $HOME or networked X11
> >   displays. However I think this is not
> >   realistic to achieve. Again, many programs are simply not up for it,
> >   for example because they assume that the FS namespace is identical on
> >   the bus client and the bus server. That could often be fixed but this
> >   would also have a perfomance cost since it would require data to be
> >   shoved through the bus itself. Then, there's the fw issue: there's no
> >   sane way to even get a TCP connection reliably established between the
> >   machine running the X11 display and the app. Finally, let's not forget
> >   that the emphasis of networked computing is more on VNC these days,
> >   less on X11.
> 
> That's an argument against network transparency.
> It's orthogonal to the scope of the bus.

Nah. I am just saying that we should declare that the session bus has
machine-local per-user scope. The network question is at the core of
what the scope of a bus is. So far it has not been clear what the scope
of the session bus actually is.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4