so the kernel can send d-bus messages

[Maciej Katafiasz]

Dnia 24-07-2004, sob o godzinie 22:40 -0400, Havoc Pennington napisał
(a):
> On Sat, 2004-07-24 at 21:10, Maciej Katafiasz wrote:
> > Let me point again at:
> > http://freedesktop.org/pipermail/dbus/2004-July/001301.html
> 
> I'm really talking about the system bus here, and the case of restarting
> it, not the case of it crashing or the case of the session bus.
> 
> For the session bus it is the single special process that should define
> the scope of the session and track the lifecycle of other processes.
> There is no reliable way to track the lifecycle of the bus itself, you
> need a "grounding point" that is assumed to never crash. Thus crash
> recovery or restart for the session bus will kill the session and is not
> supposed to happen.
> 
> The obvious grounding point is the X server, but for various reasons
> people don't want to require X for everything in the session, so we need
> a second grounding point, and that is dbus-daemon.

I never liked idea of X server bringing down whole session, but OTOH I
do understand it'd lead to doubling program logic if we were to support
crash recovery without much real gain. So I won't argue furthere here.
But I must ask - why is the default socket for session bus name
constructed by appending random junk to /tmp/dbus, instead of
predictable scheme like /tmp/$username/dbus-session? If it's for
security reasons, aren't permissions enough to make sure noone's trying
to spoof? That would eliminate need for the env variable set in 95% of
cases (ie. all default setups).

> > This leads to more general question - as I'd REALLY like to get rid of
> > env vars for that type of settings, where is the correct place to find
> > people interested in (and more importantly, capable of) doing that?
> 
> As far as I know, your problem here is not lack of people, but lack of
> feasibility. You can't have a swarm of processes that magically
> associate with each other. There has to be something that associates
> them into a session. That thing is dbus-daemon, in a dbus world.
> 
> Right now (for a GNOME session) the answer is gnome-session and the X
> server. And guess what, they both use an environment variable. ;-)
> 
> For the system bus, it isn't a "grounding point" or "session definition"
> because the kernel plays that role instead.

That isn't exactly my point. Let's leave aside session bus and grounding
points for a while, what I'm seeking for is a way to store and _change_
settings currently managed with env vars, similarly to what XSETTINGS
mechanism provides for X. That would be one part (apparently, the easy
one) of solution for "how to change locale session-wide without logging
out" problem (the second one is of course refactoring apps around
changing values of LC_*, that's particularly big undertaking, but I
digress). 
One could argue GConf already provides that, but GConf is too complete,
too high in stack, and has too many dependencies to really be feasible
solution, and also doesn't do exactly what's needed (ie. you can't have
possibly separate settings for some apps). Ideally, that would be
kernel/libc-level mechanism, just like env vars are today, but that has
some issues with portability to non-Linux (and maybe *BSD) Unices. What
is needed is some way to get easy, light, changeable at runtime env vars
on steroids.

I hope I was clearer this time, and that someone indeed knows how to
achieve that :)

Cheers,
Maciej

-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 at wp.pl>
       http://mathrick.blog.pl