ServerDataModel

This is going to grow rapidly, but I just wanted a place to throw out potential data models before I jump into writing the server side of Tin Can. These represent only the server’s INTERNAL DATA MODEL, which is distinct from the EventModel that describes the kind of events that can be triggered that change this state in different ways.

Open Questions

• Should these objects maintain some kind of history in their live representations? All that will be available in the event logs (and can be simulated from those logs to recreate states) but should objects keep any of that in memory? It’s a bit of a memory hog to store that stuff in RAM, but it’s also a problem to read it in quickly. The only reason I can really imagine we would need this is for some kind of undo operation, but given the general lack of destructive options, I’m not sure that’s a big problem.

Overview

1. Room
2. User
3. Task
4. Meeting
5. Topic
6. Resource (URL, ala sharemote)
7. Sketch (v2)

Room

Rooms are places where meetings happen. All meetings take place in a room, rooms can contain one meeting in a time. As an organizational metaphor, I like rooms because you can say “we’re meeting in [ROOM NAME]” instead of saying “I’ll email you the dial in code, because I’ve forgotten it.” Room selectors are the first UI element that people will be shown on any device. For iPads, it will say “Pick a room”, on the web interfaces, it will say “pick a room” and then “identify yourself”.

Room Fields

• UUID (saved)
• name (saved)
• currentMeeting

Meeting

Meetings are top level organizational objects for pretty much everything else that happens. All other objects will have references back to the meeting in which they occurred. A meeting object is created whenever someone enters an empty room. Meetings are closed when the last person leaves. (We might want to add some sort of continuation ability in case a meeting takes a break or something.)

Meeting Fields

• UUID
• roomUUID
• meetingTitle (optional)
• startedAt
• (endedAt)
• allParticipants (All)
• isLive – true if the meeting is currently going on
• currentParticipants (Current)

User

Tracks meeting participants. There isn’t a formal registration system per se, people get added primarily from the web interface, when it asks someone to identify themselves. All known users get kept around in memory and tracked on disk between startups/shutdowns. Might add some kind of user co-occurrence thing later to make good suggestions about which users might be likely to be in a meeting. (Don’t like the name, but alternatives aren’t great.)

User Fields

• UUID
• name
• inMeeting – link back to the meeting they’re currently in (or false if not in a meeting)
• loggedInStatus – enum for: mobile web, web, not logged in
• status – enum for participation options, things like writing a todo, taking minutes, adding an agenda item, etc.

Task

A task that someone can do. Tasks are created by specific users and assigned to specific users.

Task Fields

• UUID
• text
• meeting – link back to meeting
• createdBy – link back to user
• createdAt – time created
• ownedBy – link to the user who currently owns it

Topic

An agenda topic.

Topic Fields

• UUID
• text
• meeting – link back to meeting
• createdBy – link back to user
• createdAt – time created
• timeStarted – when the agenda topic started in the meeting
• timeEnded – when the agenda topic ended