D-Bus User Bus
mzqohf at 0pointer.de
Wed May 19 18:50:40 PDT 2010
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
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.
> > - 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
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 Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the dbus