User bus conclusion

Ralf Habacker ralf.habacker at freenet.de
Wed Nov 10 22:20:01 PST 2010


Am 10.11.2010 16:29, schrieb Havoc Pennington:
> Hi,
>
> On Wed, Nov 10, 2010 at 10:24 AM, Lennart Poettering<mzqohf at 0pointer.de>  wrote:
>> Well, I think we definitely want to inform the apps that they are
>> actually on a user bus. That's why I think Ryan's request to name this
>> bus differently if we share it between logins makes sense -- even if we
>> actually redirect all apps to the user bus if they ask for the session
>> bus.
>>
> Just rephrase it. "to inform apps that sessions are per-user and not per-login."
>
> What you're calling user bus is _not_ what it's ever been in the past
> on this list, and it's just not a good name. What you're proposing to
> change is the model for _sessions_.
>
> It's a stronger, more useful guarantee for apps if you change
> _sessions_ to be singleton. In fact, I continue to think what we've
> always called user bus - a bus spanning sessions - is a bad idea. I
> think what you guys have really hit on is that the right fix is not to
> have a user bus, but to have a user session. The whole problem with a
> user bus was that it had multiple sessions on it. You've fixed that by
> uniquifying the session, instead of the bus. The bus just gets
> uniquified as a side effect.
May be the way the implementation on windows moved on may solve the 
problem - There are dedicated session busses required with special 
features which has been implemented by adding a scope parameter to the 
autolaunch transport  
(http://cgit.freedesktop.org/dbus/dbus/commit/?id=2e61875728deca49a96e2db52275f3a5e24bb59b) 


(may be better named meta-transport because of 
http://lists.freedesktop.org/archives/dbus/2010-October/013581.html)

To have user session busses a special address on the server and client 
could be used limiting the session to a specific user.  On windows this 
would be

autolaunch:scope=#user

or something else (this has not been defined yet)

Regards
  Ralf








More information about the dbus mailing list