-
Notifications
You must be signed in to change notification settings - Fork 77
Multiple Sessions
There are a few reasons to want multiple "sessions" in a single running instance of Mattermost.
-
For one, Mattermost already includes the notion of multiple "teams", which show up in the web interface as selectable squares off to the left:
It would be nice to have a story for belonging to multiple teams other than, "Just run multiple copies of Matterhorn."
-
For another, it would be nice to use a single running instance of Matterhorn to talk to multiple Mattermost servers. This is a feature of mobile clients for Slack-like clients, where you might want to pay attention to several servers you belong to at once.
-
Finally, this would help future backend/frontend separation, and maybe eventually allow easier interaction with other chat services, as well.
There are two parts to this proposal: what this should look and behave like to the user, and how this should manifest itself in the code. Right now, my proposal is
- represent teams/sessions as a tabbed system only if the user has multiple sessions configured. Otherwise, it should appear exactly as it does at present. This also would only take up one (or two, with border) rows, whereas doing columns along the left would take up more rows.
- Keypresses should cycle between sessions, and there should be some
C-g
equivalent to select a named session - We need some way of defining new sessions, both in configuration and in the running client
In the backend:
- We take the current
ChatState
type and move many of the fields to another type calledChatSession
. TheChatState
type gets aZipper
ofChatSession
values (at least in theory—a different structure might be better!) Things that are UI-related—for example, the current theme—will stay inChatState
, but things like user lists and post maps move to the newChatSession
type. - Almost everything that operates on a
ChatState
value now operates on the focus of theChatSession
zipper now. - There will be a new websocket connection per each
ChatSession
, and event-handling needs to know what session is associated with an event, so that posts can be added to the appropriate session. - We need activity notifiers on two levels of granularity: notifications for channels within a session, and notifications for a whole channel if there's any activity in the channel at all.
More details might need fleshing out in the future, too.