One user morne than one time logged in.
hp at redhat.com
Wed Jan 25 22:34:14 PST 2006
On Wed, 2006-01-25 at 17:53 -0500, Daniel Macks wrote:
> There are lots of login routes and dbus usages that don't rely on the
> concept of a "desktop session". How about servers that are accessed
> via remotely (say I open two ssh connections), or OS X, where the
> "local machine shell" widget does not have the concept of a session or
> a startup script from which to launch the daemon?
dbus is very explicitly designed for only two use-cases; one is a
GNOME/KDE style "desktop session" and the other is the systemwide bus on
Linux or similar systems. Anything else is bonus, only if it doesn't
break or complicate the core two use cases. There are plenty of fully
generic IPC systems in the world already.
> Too bad I found bugzilla and rambled off a proposed solution before I
> found this mailing list...
What you describe there is how gconfd originally worked, it has too many
problems and we had to drop it.
- the home directory can be shared between two sessions on different
machines or networks; if you scope the daemon to homedir, not
all sessions using that homedir can necessarily connect to the daemon
- having a daemon persist after logout breaks multiuser systems pretty
- you can't reliably do file locking on NFS, and homedirs can be on
NFS; this is another practical barrier to implementing per-homedir
It just doesn't work. It's been tried (not only with gconf; various
bonobo-based daemons also messed with non-per-session semantics and were
also weird and unreliable in the presence of multiple sessions).
per-user is not useful if it has weak "maybe" semantics. It's only
useful if it's absolutely guaranteed to produce a per-user singleton,
and that is not possible if you can only assume a shared homedir. It is
possible if you can assume a network server like IMAP, but few apps are
willing to require that.
More information about the dbus