Technical discussion

[Samuel Iglesias]

Right now our mockup, which can be found at http://bit.ly/classpulse,
is written using an HTML 5 canvas, Javascript, Tornado server
technology, and Django and Python as a backend, with MySQL currently
serving as our database (although we aren't storing anything). Do you
have any technical objections to our using these technologies? Do you
have any suggestions?

[Andrew First]

These technologies sound good. You can use the MySQL database for storing the module and class information, and any other persistent data. The danger of keeping things in memory (and not in the database) is that if the server were ever to go down, or whenever you wanted to push updates to the server, you would lose that data.

It's difficult to allow users to create their own modules from scratch for a number of reasons. I would make a bunch of premade modules that allow customizations, and have interfaces to both the Python and HTML/Javascript side of things. Then, I would also store the module information in the database along with the professors' customizations.

More technically, the realtime interface currently happens in both the NotifyController and the SubscribeController. The NotifyController tells the server when the user made some sort of input, so that's where you would demultiplex your input to the different modules. The SubscribeController fires whenever an update on the server occurs, or when a user requests an update, so that's where you would multiplex the state from all the modules into JSON that can be read by the modules running on the client side.

As far as UI goes, each module can have three views -- one for the student, one for the professor, and one for customization preferences.

Let me know if you would like any clarifications, suggestions, or if I left anything out.

[Andrew First]

Here's some more detailed technical notes:

Adding the classroom ID

Create a dictionary mapping client_id to info about the user

- Whether the user is a student or an instructor

- The classroom ID

When you go to the site…

- If we don't know if the client_id maps to a student or instructor, show the Student/Instructor screen

- Otherwise…

- If we don't have a classroom ID or the classroom ID is invalid, prompt for the classroom ID

- Otherwise…

- Show the classroom interface

Within the classroom interface, you could present options to switch classes or leave the class. Should there be some way to save the class info so you don't have to input your preferences each time you do a new class?

I think there should be some way for the instructor to say which module is active or to change which modules are available in real-time. For example, if the instructor wants to launch a poll, all the students should see the poll at that moment.

To do the classroom codes, you'll need to modify the SubscribeController:

Right now, SubscribeController.clients is a dictionary mapping a client_id to a SubscribeController object. You should modify this to be a dictionary of classroom IDs mapping to client_ids mapping to SubscribeController objects. Additionally, the active_count is an integer right now, and should be a dictionary mapping client_ids to the counts.

To delete a class after 2 hours, you can use the timeout functionality built into Tornado, like in this line in the SubscribeController.on_connection_close:

IOLoop.instance().add_timeout(time() + SubscribeController.INACTIVE_TIMEOUT, self._check_stale)

Modules

The last static variable, total_score, needs to be abstracted away into a voting module. To do this, look at every place that total_score is referenced, and think about how this would be made generic to any sort of action on a module. Then create a Module interface (a class with empty methods)  and a VotingModule class that extends Module. Place the total_score logic in VotingModule.

To organize the modules, I would create a directory called modules within the project directory, and create another directory for each module. In those directories would be the python class for the module logic, and also the UI files.

You can rename base.py to controller.py, and create a new module.py in the core directory which would contain the Module interface.

On the UI side, you could put each module in an frame, so wherever it wants to load a module, it will load the module's URL in an frame.

Database

You'll want to create a database using MySQL. Follow the Django instructions on how to do this…it will be exactly the same and you can use Django models.

You can store any persistent info you want in the database, such as the ability to remember the instructors preferences across multiple classes, or any other persistent data or statistics.

Email

Email is tricky, You'll probably want to set up a Google account for your domain that you can use as an email server. I have some Django code that handles email, but it requires the database to be set up first. Let me know when you're ready for that.

Memory Management

- One way to approach it is every time info is added to the client_id dictionary, you'll want to check for stale data as well. An example of this is already done in the SubscribeController._prune() method, which his called when a new SubscribeController is added. The client data would take a lot longer to expire though, and you should bump the update time whenever the client makes activity.

If you're storing things in the database, there is less concern for deleting old records because the size of the hard disk is much greater than the size of memory.