Skip to content

Multiple Sessions

G. D. Ritter edited this page Sep 18, 2017 · 1 revision

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:

    team select screenshot

    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

  1. 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.
  2. Keypresses should cycle between sessions, and there should be some C-g equivalent to select a named session
  3. We need some way of defining new sessions, both in configuration and in the running client

In the backend:

  1. We take the current ChatState type and move many of the fields to another type called ChatSession. The ChatState type gets a Zipper of ChatSession values (at least in theory—a different structure might be better!) Things that are UI-related—for example, the current theme—will stay in ChatState, but things like user lists and post maps move to the new ChatSession type.
  2. Almost everything that operates on a ChatState value now operates on the focus of the ChatSession zipper now.
  3. 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.
  4. 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.

Clone this wiki locally