I understand that unsetting the environment variable is a work-around, and it's looking like we will need to use for now, but it would seem to make sense that d-bus needs a way to auto-launch yet avoid lots of instances for the same user, I feel that this is going to become even more important if GConf is going to totally move to using D-Bus as it's IPC mechanism.
As I understand the way that d-bus locates it's service, it does one of the following:
1) Look for DBUS_SESSION_BUS_ADDRESS
2) Look for an XAtom
3) Look for address in a file in ${HOME}/.dbus/sessionbus
If we do auto launch then shouldn't we try to avoid that there is more than one for any given user, i.e. re-use an existing session if it exists?
I actually think that this is not unique to GConf, it's just that GConf is highlighting it now.
On OpenSolaris we have to also contend with applications that get launched in a separate Zone, which is like a chroot environment but totally isolated all the way into the kernel - this presents issues too with apps that require D-Bus since Zones are not UI environments usually.
Again, while we could spawn a specific session bus, in a zone there is no X, so we would rely upon environment variables and/or the file in ${HOME} to locate an existing session bus.
I understand that unsetting the environment variable is a work-around, and it's looking like we will need to use for now, but it would seem to make sense that d-bus needs a way to auto-launch yet avoid lots of instances for the same user, I feel that this is going to become even more important if GConf is going to totally move to using D-Bus as it's IPC mechanism.
As I understand the way that d-bus locates it's service, it does one of the following:
1) Look for DBUS_SESSION_ BUS_ADDRESS
2) Look for an XAtom
3) Look for address in a file in ${HOME} /.dbus/ sessionbus
If we do auto launch then shouldn't we try to avoid that there is more than one for any given user, i.e. re-use an existing session if it exists?
I actually think that this is not unique to GConf, it's just that GConf is highlighting it now.
On OpenSolaris we have to also contend with applications that get launched in a separate Zone, which is like a chroot environment but totally isolated all the way into the kernel - this presents issues too with apps that require D-Bus since Zones are not UI environments usually.
Again, while we could spawn a specific session bus, in a zone there is no X, so we would rely upon environment variables and/or the file in ${HOME} to locate an existing session bus.
What do you think?