EventModel

The Event model serves two purposes:

1. Serve as a logging mechanism that will give us substantial analytical tools when we deploy.
2. Provide state backup so when the server shuts down, it can re-load/re-play logged events to recreate current meeting state in active meetings.

These two problems are unified with the REST API provided by the server, such that every event that comes from a client gets converted into an Event object and those events are then dispatched to the logging mechanism and the applied to the server’s internal state.

Events are not just a tool for communicating between client and server. Any server state change generated by the server operates on events as well. In practice, this means that you can’t call, for instance, something like meeting.userJoined. Instead, you’ll need to generate a JOINED event and send it to the event dispatcher. It will be up to the dispatcher to send it to the right meeting and have the meeting do the right thing. Doing it this way means that we’re nicely unifying the logic paths. Anything that changes the state of the server triggers an event. This makes it impossible to forget, which makes the two benefits described above super secure. So the process for changing any internal state looks like:

• Create an event object representing what is happening.
• Pass that event object to the event dispatch
• Event dispatch routes it to the right handler
• Handler changes internal state.

Event Structure

• uuid – the uuid for the event. These aren’t really used (and events are not stored in the main event repository), but I have a feeling I might want them for client-event-receipt-acknowledgement, so they’re in the object for now.
• eventCode – an enum specifying the kind of event. First pass at potential event codes available below.
• timestamp – the time when the event was created on the server.
• userUUID/user – the user that originated the event. In cases where it’s a server-level event that doesn’t have a user, yarn.SERVER_UUID can be used instead. Don’t think we have any of those cases yet, though.
• params – a dictionary that holds all the non-optional event parameters that are not shared by all events. EG, not all events have a room attached to them, so ones that do require it will have it stored in this dictionary.
• results – a dictionary of objects that are results of this event being executed on the server. For instance, the user in a join operation or the meeting in a new meeting. These are distinct from the parameters of the event because normally we just provide UUIDs of objects the clients should already be aware of, but in this case they represent new objects that clients might not be aware of.

Event Codes

• NEW_MEETING
• JOINED
• LEFT
• NEW_TASK
• UPDATE_TASK
• NEW_TOPIC
• UPDATE_TOPIC