DBUS_SESSION_BUS_ADDRESS related Qs.

[Havoc Pennington]

Krishna R wrote:
> Thanks for the reply, it was very useful to know!
> 
> One of the ideas i had was reading the address from a file instead of 
> the env. I am thinking of using dbus for simple IPC within a pc.
> 
> I did not understand what you meant by...
> 
>  >  - file in homedir - doesn't solve this due to
>  >   locking/network-file-system problems
> 

"gconfd" tried to work this way.

First, if you do one daemon per session, then how does each app know 
which file to read? In other words, how does the app know which session 
it's in? The answer will probably be one of the other two things - a 
property in X or an env variable. So then the file isn't doing anything, 
since you could just put all the info in the X prop or env variable, and 
the file is pointless.

If there's one global daemon for all sessions (the way gconfd tried to 
work), then there's just one filename, and apps don't need to know their 
session. However, you need to have just one daemon. That means some type 
of file locking. Unfortunately, in practice file locking in home 
directories is broken in lots of deployments (judging by number of bugs 
filed). Also, some deployments use AFS which means they share the 
homedir among machines that have firewalls between the machines. So apps 
can't talk to daemons on other machines.

The bottom line is that you need something that defines a session; 
either X server, process tree (env variable), or dbus session daemon. 
The current approach is that all three of those define it and are 
supposed to go together.

Havoc