System Architecture

This page describes the current architecture of the timetable system.

The architecture quite closely resembles REST's concept of resources and representations. Our central resource is an entity representing lectures of a part of a tripos (each of which are stored in a details*.json file). The representations are derived from this resource, and take the form of CSV spreadsheet data, ical feeds, gcal feeds etc (similar to REST's GET). Some representations can be used to modify the resource they were derived from (similar to REST's PUT). Some representations (such as ical) are lossy, and so it wouldn't make sense to re-create a resource from them as you'd lose data.

The system currently statically generates all available representations of the timetable resource whenever it changes. From conversations with others in CARET I've been informed that the reason for this (rather than dynamic generation of views on request) is that Dan was concerned about the performance of the site.

Hal's Thoughts On Static Generation of Representations

I wouldn't go as far as to say pre-generating all the view representations is premature optimisation, as the code which builds representations is quite slow, but I do think this is not the best way to go in general. I can't see any inherent reason why the generation should be slow, and even if it is I'd argue that it would be better to generate representations on demand and ensure they're cached outside the application (by the webserver or a cache in front of the server).

Additionally, I'm told the reason for storing the resource as a JSON document in flat files was to do with a desire to use a document database such as Couchdb, but lack of time to integrate such a database. So essentially for simplicity. I believe it was thought that an SQL database would not be a good fit for the problem, perhaps because of the fast changing nature of Dan's data (as he came across new edge cases and requirements from new departments).

Dan's Architecture

Dan's central architectural idea was (apparently) to have one root data representation with several distinct views on that data. It should be possible to generate an instance of the root representation given any child view of the root.

For example, one might have a spreadsheet view of the root data. This spreadsheet could be edited and then used to generate a root instance which reflects the changes made to the spreadsheet.

The idea (I imagine) is to reduce complexity by eliminating the need for child views to know about each other. All a child view (of the root) must provide is a means to generate itself from the root, and a means of generating a root from it.

One potential issue is that data could be lost if a child cannot represent the full data of the root. This could potentially be mitigated by providing an instance of the previous root when generating a new root from a child, allowing blanks to be filled in.