Bug #42
Make Core multi-user capable and clean up architecture
| Status: | Closed | Start date: | ||
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | Sputnick | % Done: | 0% |
|
| Category: | Quassel Core | |||
| Target version: | 0.2.0-alpha1 | |||
| Version: | OS: |
Description
As planned for quite a long time, a quassel core should be able to handle multiple users simultaneously in order to, for example, allow shared hosting solutions. This also includes user authentification (BR #17).
As it turns out, this involves major changes in the Core architecture, an opportunity which I will use to also clean up things a bit. Things that come to mind:
- Core functionality needs to be split into global and user-specific parts (classes Core and CoreSession)
- Global data (class Global) needs to be handled per-user
- CoreProxy needs to be user-specific, so I'll transform it from a pseudo-singleton to a proper object, with one instance per user
- Connection handling moves from CoreProxy to Core
- User auth will be part of Core (BR #17)
A question that comes to mind: Do we ever end a user session? Even if all GUIs disconnect, the session should continue running. What happens if core executions ends - should we save active sessions and restart them when the core is restarted, or should we rather wait for a GUI to log in and explicitly get a session started for the particular user? An admin mode comes to mind, where active sessions can be monitored (stats) and sessions started/stopped...
If we plan to automatically restore sessions, does this involve reconnecting to all nets that where connected at shutdown, and joining all channels? Or should we only reconnect/join stuff that is marked as auto-connect and auto-join in the appropriate preferences?
Related issues
History
#1 Updated by Sputnick almost 5 years ago
Done. Has not been tested with more than one user though, since we don't have auth yet.