User bus conclusion

[Havoc Pennington]

Hi,

On Wed, Nov 10, 2010 at 8:38 AM, David Zeuthen <zeuthen at gmail.com> wrote:
>  - we leave the session bus alone
>   - that way we don't break existing apps or setups
>  - we add a new user bus; call it LOCAL_USER

To me, the new bus / new API breaks existing apps and setups MORE.
That's what I don't understand. Making two buses is just punting a
bunch of complex questions to app authors (that really haven't been
answered yet in this thread, I suspect the people in the thread don't
all agree even if just considering those of you who were in the room,
but anyway they aren't written down).

>  - we add some helpful docs explaining when to use the SESSION bus

Having the docs first before starting to make changes might go a long
way to sorting out this thread. I would say:

* what are apps supposed to do, in all main cases you can think of,
INCLUDING nondefault configurable possibilities you don't want to
declare disallowed
* how does the su/sudo problem get solved. what are you declaring to
not work / never support
* what happens with shared network homedirs
* how does ssh work; what works, how, what will never be supported

>   - FWIW, I don't think it's hard to come with examples for both
>     - LOCAL_USER: Vfs, Settings etc.

These can perfectly well use SESSION if the session bus is unique on
the host/machine. So that's what I'm saying; all you need to do is
make your OS change so there's only one session on the machine. Done.
No dbus API changes. No app developer complexity. No confusing two
kinds of bus.

Apps can now choose to only support an OS configured in that way;
optionally, add an API call to ask if the OS is so configured, like
bus_is_per_user_on_host() - though I think the main use of that API
would be to fail and abort on unsupported configs.

>     - SESSION: e.g. panels, authentication dialogs, other
>       per-session stuff

USER and SESSION simply are not different, in your proposed OS
configuration where all logins join the same session. panels, auth
dialogs, etc. are per-X display, not per login. and thus they are
per-user-on-host if you limit to one X display at a time.

I don't understand how it _works_ to have _both_ buses. I really hate
the proposal to have two, or worse, to configurably allow some OS's to
have two, sometimes. If that's going to be allowed, the docs better
spell out how it works too. But I think it fails a basic complexity
threshold that dbus is probably already beyond, even as it is.

Havoc