multiple KDE sessions support (was [dbus] Re: Cmake update patch for dbus master)

[Ralf Habacker]

Ralf Habacker schrieb:
> Romain Pokrzywka schrieb:
>   
>> (nb: Forking from the thread on DBus, since it's more of a KDEWin issue than a dbus one)
>>
>> On Monday 15 February 2010 03:12:50 Ralf Habacker wrote:
>>   
>>     
>>> Ralf Habacker schrieb:
>>>     
>>>       
>> [...]
>>   
>>     
>>> A possible implementation could extend the autolaunch bus address type
>>> with a scope attribute
>>>
>>> autolaunch:scope=<value>
>>>
>>> where value could be the predefined term 'install-path'.  If the server
>>> find such a session bus address it will listen on a free tcp port and
>>> publish the recent session bus address in a shared memory segment, which
>>> is postfixed by a hash value of the libdbus installation root. Every
>>> client which uses the same session bus address would be able to connect
>>> the related daemon.
>>>
>>> There is also an additional feature available by using this scope
>>> attribute. Any non empty value except the above mentioned 'install-path'
>>> value will create a specific namespace and could be used to create
>>> specialized dbus session buses.
>>>
>>> This feature will be enabled with a (cmake) configure option named
>>> DBUS_USE_LIMITED_SESSION_DEFAULT_ADDRESS.
>>>
>>> Any comments or addons ?
>>>     
>>>       
>> (nb: context: we are discussing options for having multiple KDE-windows releases running side by side, with a dbus 
>> session bus for each and with KDE apps from each release talking to their matching daemon)
>>
>> I'm not sure if this is the right place where the issue should be addressed, at least in the KDE-Windows context.
>>
>> Regarding sessions started from a kdeenv.bat console, the problem is solved: adding a DBUS_SESSION_ADDRESS env var to 
>> kdesettings.bat is trivial and does exactly what we want (whoever needs it can adjust it for each concurrent session 
>> bus).
>>
>> For sessions not started from a console, such as releases from the installer, I'm not sure if it's really a use-case 
>> worth being considered. 
>>     
> This is the default case on windows. Every KDE package installed by any 
> type of any single click or other installer will probably have start 
> menu entries and the related applications will *not* be started from a 
> console. With your statement above you say that there is only one KDE 
> package startable from the start menu. Any additional packages should be 
> started from the console and is not allowed to have start menu entries. 
> Makes this really sense ?
>
> BTW: For those who do not know already: Creating start menu entries is a 
> build in kdebase runtime feature since about two years - see 
> http://websvn.kde.org/trunk/KDE/kdebase/runtime/platforms/win/kwinstartmenu/readme.txt?view=markup 
> for more informations.
>
>   
>> Will users often have multiple versions installed side by side ? 
>>     
> yes. For the kde on windows community release: there are three branches. 
> stable,unstable and nightly. They can be installed and updated 
> independently from each other and they are uses all three. The only 
> issue currently is the shared dbus session bus which makes it impossible 
> to make sure, that applications reachable over dbus are from the same 
> installation path.[1]
>
> In the kdepim enterprise world I guess there will be also at lest two 
> binary package branches, stable packages and unstable/development 
> packages. If you have only one session bus you will have also troubles 
> to distinct applications reachable over dbus. You cannot be sure that 
> applications from the stable package will use applications reachable 
> from dbus from the stable installations. This results into a support 
> night mare isn't it ?
>
>   
here is a detailed example:

Assume you start umbrello release - this will call - from the release 
installation - kdeinit4, which will start dbus-daemon, then klauncher 
and kded. Then on request klauncher will start kioslaves from the 
release installation.

Then on umbrello debug, unstable or nightly start from a separate 
installation (a separate installation is required on windows) - it will 
call - from the debug installation - kdeinit4, which detects that 
release dbus-daemon is already running, a klauncher is already 
registrated and kded too. Then on request debug klauncher will start 
release kioslaves and any other requested application from release 
installations - which is *not* intended for a debug, unstable or nightly 
installation.

Ralf