Cmake update patch for dbus master

[Romain Pokrzywka]

I've been playing a bit with multiple sessions buses now, and here's a quick feedback. Basically it works, but it has 
some shortcomings :

- you need to adjust the port used in two places : the session.conf file for the daemon, and the 
DBUS_SESSION_BUS_ADDRESS environment variable for the apps. having one place where this could be done would be less 
error-prone.
- once you use the env var you lose the autolaunch feature (maybe that's a windows-only feature though, I dunno)
- the fact that all the buses use the same shared memory segment to store the session bus address means that an app 
running without the env var will be talking to an undefined session bus (ie. the last one that updated the shared memory 
segment)

Based on the above, and if having multiple running session buses is really a scenario that's considered (besides KDE on 
Windows, I can think of security reasons, sandboxed environments, user privileges...), then I guess Ralf's argument and 
proposal is still worth discussing and elaborating. The current solution is working, but it's not perfect.

Best regards,

Romain


On Tuesday 09 February 2010 06:58:53 Thiago Macieira wrote:
> Em Terça-feira 9. Fevereiro 2010, às 09.29.43, Ralf Habacker escreveu:
> > > Since the wire protocol is the same, there's no reason why a debug-mode
> > > application should have to link to a debug-mode daemon.
> >
> > I understand - but how to ensure then the use case Romain (and others)
> > talked about:
> >
> > "... require to have different dbus session buses running for a single
> > user.
> >
> > "Definitely. That's something that could be useful not only for the debug
> > vs. release case, but also for different versions of KDE apps running in
> > parallel. For example, I usually have a stable KDE-Windows build for my
> > common apps, then I have an enterprise4 branch build for Kontact, and I
> > also keep a trunk build for testing and development. Currently I have to
> > kill all processes (including dbus-daemon) everytime I need to switch
> > between those, which is a PITA. "
>
> I'd say the answer should be "Use the same technique as on Unix"
>
> If you require different busses, you just set a different environment
> variable (DBUS_SESSION_BUS_ADDRESS). It will be inherited by all processes
> in that session.
>
> What's more, I don't see what D-Bus busses have to do with different KDE
> builds. You can use the same, running dbus-daemon.exe with different KDE
> builds. Kill all KDE processes from one build, then start them again from
> another.
>
> > On command line one can set easily an environment variables to instruct
> > the dbus client where to contact the dbus daemon, but how to ensure this
> > for KDE releases on windows.
>
> You don't, same as on Unix.
>
> If there's no bus running, it will use the shared memory segment to get the
> address, starting the daemon if there's no bus running. (Same as on Unix).
>
> If the DBUS_SESSION_BUS_ADDRESS variable is set, use that. (Same as on
> Unix)
>
> > dbus is not part of the windows operating system and is not started on
> > user session startup as on linux - dbus is a part of  every KDE release
> > may it be stable/unstable/nightly or local development.
> > KDE applications are started mostly from the start menu, so environment
> > settings like DBUS_SESSION_BUS_ADDRESS will not work here or are not
> > uniq for one dbus.
>
> Same as on Unix (if that's a Unix where dbus-daemon isn't started, which
> still exists).
>
> > Technical is is possible to run one dbus-daemon for all releases, but
> > which klauncher/kded  will then be started ?
>
> Those are not started by dbus-daemon. There's code in kdelibs/kdecore to
> start kdeinit4, klauncher, kded4, etc. That's where the path is determined.
>
> In theory, it would be possible to run two sets of those applications on
> the same computer, by the same user, if they were in separate buses. But at
> least on Unix, kdeinit4 also creates a socket which is keyed to the X
> display, so it wouldn't work -- on Windows, it may.
>
> > I guess from the release
> > from which I started the first application. Assuming this release is my
> > daily work release - as Romain said, when I need to restart the
> > development release I have to restart my stable release too - this is
> > bad.
>
> See above.
>
> And even if that were the case, you could override by starting those
> applications yourself.
>
> > The conclusion is there must be a way to separate a dbus-daemon to a
> > specific release. But how to implement such a feature ?
>
> I disagree that there is such a need.
>
> [snip the rest]



-- 
Romain Pokrzywka | romain at kdab.com | Certified Qt Software Engineer & Trainer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions