[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-dbus
Subject:    Re: Cmake update patch for dbus master
From:       Romain Pokrzywka <romain () kdab ! com>
Date:       2010-02-17 2:04:19
Message-ID: 201002161804.19486.romain () kdab ! com
[Download RAW message or body]


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@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
_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus


[prev in list] [next in list] [prev in thread] [next in thread]