It’s all been a bit quiet on the Total ReCal front for the past week or so, but not because we’ve been quietly doing nothing. Instead we’ve been quietly working on the supporting systems which let Total ReCal do it’s thing without needing to handle every single aspect of time/space management, user authentication and who knows what else.

The first thing we’ve got mostly complete is our new authentication system, built around the OAuth 2.0 specification (version 10). For those of you unfamiliar with OAuth, it’s a way of providing systems with authorisation to perform an action without actually giving them a user’s credentials, much as modern luxury cars come with a ‘valet key‘ which might provide a valet with limited driving range, limited top speed and no ability to open the boot. In the case of the University we’ve come up with a service whereby a user (in this case a student or staff member) issues authorisation for a service to access or modify data stored within the University on their behalf.

Taking Total ReCal the example, the user would issue a key which allows Total ReCal to read their timetable, assessments data and library data (from which it can extract various events such as lectures, hand-in dates and book due dates).What it doesn’t give is permission to read personal details, to book rooms under that person’s authority, to renew library books or indeed anything else which requires a specific permission. In addition to this, Total ReCal never sees the user’s authentication information – it simply doesn’t need to because the key it’s been given by the user is authority enough to do what it needs.

We need OAuth for a variety of reasons. First of all, we were getting bored of having to write a whole new authentication system for every single application, and this makes our lives much easier. Secondly and more relevantly we want Total ReCal to be a demonstration of the Service Oriented Architecture way, showing that it’s possible to make use of small, focussed services which we bolt together as we need rather than monolithic applications which do everything, but don’t play nicely with other monolithic applications trying to do everything. Authentication is a key example of this since it’s something in common to almost every application. Thirdly, we want to be able to explore more ways of giving the user control and this is one of them. By relying on the OAuth authorisation route, users are given crystal clear information on what Total ReCal is, what it does, and how it intends to use their information. It’s then up to the user whether they want to use Total ReCal or not, and they can revoke the permission at any time. In future we hope to see lots more applications take this route, not necessarily just from within the University but also from outside.

We’ve also been working hard on yet more of our Nucleus initiative to provide coherent APIs to the University’s core data. Much of Nucleus has been waiting for the arrival of the authentication and authorisation services provided by OAuth, but now that is completed we can really get cracking with the bulk of the system.

Nucleus is needed for Total ReCal since it provides both the source data for a lot of things, and storage methods for other bits. Much of the time-based data we need will be made available in the Nucleus Events service (such as timetables or a user’s room bookings), which is a central place to look things up rather than having to make calls to different services around the University. Nucleus Events is also the storage place for new data created through Total ReCal’s data extraction plugins, so once a user grants us permission to have a look at their Blackboard account we can extract things like assessment due dates and push them back into the centralised storage.

This model has the wonderful side effect that people using Total ReCal will automatically have these dates appear as items in other systems, for example if we one day build an Events plugin for Blackboard it will seamlessly pull Library due dates back from Nucleus. It also ties into our planned support for things like our new VRE, so that we can push and pull a single instance of an event in our database into multiple places and multiple people’s calendars and even manipulate it using other systems without breaking things.

Unfortunately these two services aren’t ‘officially’ classed as part of Total ReCal despite their necessity for it to function, and as such we’re unable to release all the source and complete details of the inner workings to the wider community. We will, however, be thoroughly documenting all our interfaces for both including clear pointers as to where they abide to existing standards (if any), where they differ (and why) and where we’ve just had to make it up because nothing exists. We’ll also be looking at the possibility of open sourcing as much of the code as we can, although for various reasons we can’t promise anything.