-
Notifications
You must be signed in to change notification settings - Fork 53
Project Architecture
In both client and server, there should be a global Channels
object available. It is a simple dictionary of channelName
to an instance of a Channel
object.
Channel
objects represent a public or private channel. They are queried for their public or private status upon creation on the server. If channel.clients.length
is 0, then we can remove this channel from Channels
.
Channel
fields include:
- name
- namespace
clients
- ...
Any authentication is queried via the channel.name
. Any events are created in the fashion of: "my:custom:event:" + channel.name + ":" + channel.namespace
For ChatServer
, channel.namespace is not relevant and can be blank (since there is not yet a concept of subchannels). For DrawServer
or CodeServer
, namespaces are important as they are essentially subchannels. Conceptually, they can also be thought of as 'files'. CodeServer
currently has 2 namespaces, one for HTML and one for JS. It could be extended to have a deeper namespace, "file1:js" and "file1:html", and so on, for multiple files and REPLs.
The client can attempt to build up a list of channels, and the server can send a (paginated?) list of all active public channels to the client upon join.
Client
stores things like:
- nick
- identified?
- lastActive
- color
When a user successfully joins a channel, channel.clients.toJSON()
is sent to the user, along with a note of which client the server considers him to be (the server's client.cid
). The client then mirrors the server's channel.clients
in this fashion.
Channel
needs to be alterable by any server modules running upon it, so that they may store custom data in this object. For example, CodeServer
stores a snapshot and a list of operations, DrawServer
stores a replay of the drawing operations. CodeServer
also wants to know the user's nickname and color, because it wants to append these to their cursors. In this sense, it would seem smart not to duplicate any Channels
, Channel
, or Client
objects unnecessarily and just transmit them once.
Thus, it seems like Channels
should be a module of its own, responsible for the transmission of the current state that a client is interested in