I will argue that the OU player project provides an ideal case study for why The Open University, including the central IT providing departments should not adopt a one-size-fits-all approach to the choice of information technologies. At present, I think they are in danger of doing this. You may also be interested in Juliette Culver's post, Why we moved from Drupal to CodeIgniter, and Will Wood's post, Agile Ballooning.
First, some background. CodeIgniter is a minimal model-view-controller PHP framework. It is open source, makes full use of the object-oriented programming paradigm, offers database abstraction, an ORM (object-relational-model) layer, and various extension mechanisms including libraries, hooks and helper functions. By default, templating/ views are implemented in PHP, though an alternative templating system such as Smarty could be plugged in. There are many third-party plugins available, and it is a simple matter to plugin other libraries, for example parts of the Zend framework. As a low level framework, its benefits are a shallow learning curve, the promotion of maintainable, well-structured code, small footprint, performance and flexibility (http://codeigniter.com).
Drupal is a fully fledged content management system. It is also open-source, and implements the functions you would expect from a CMS - user registration, authentication, roles and management; content authoring and management; themes (styles/ templates); modules (plugins); an administration interface; reports and so on. There are a wide variety of third-party modules (http://drupal.org).
Web service/ API versus content-oriented site
At its heart OU player/ OU embed is a web service/ API, with some simple demonstration and test pages.
So, fundamentally, we don’t care about managing content, which is what a content management system (CMS) like Drupal is for. As an aside, the OU podcast content is managed through a an administration interface that accompanies the public podcast web site (http://podcast.open.ac.uk).
Which parts of core Drupal would OU player use? Answer: not many.
In my estimation the following parts of Drupal would NOT be used or might need disabling:
- User registration, authentication, roles, management;
- Content authoring, management;
- Menus would only be used for page routing;
- Most of the administration interface - not used;
The following parts would be used to some extent:
- * hook_menu function - for page routing (http://api.drupal.org/api/function/hook_menu/6)
Which third-party modules would OU player use? Answer: none, or at most one or two
One of the frequently cited benefits of Drupal is the wealth of third-party modules. However, the OU player as a bespoke web-service may well not use any third-party modules in production. Alternatively, there may be a useful API helper module, and the Developer modules would probably be used in development.
Security - maintenance
Like any large, complex piece of software, Drupal is occasionally found to contain security vulnerabilities (note, not a criticism of Drupal at all). Several years after its initial release, there still appear to be 2-3 security updates for the core of Drupal 6 per year. Although much of the Drupal functionality would not be used (see above point), there would still be pressure to update to the latest version of Drupal each time.
By contrast, the core of CodeIgniter, as a small and low-level framework without features like user-authentication and content management, suffers much less from security bugs. It is anticipated that the CodeIgniter core would need to be upgraded once or twice during the life of the OU player.
Performance is very important for the OU player - it will be embedded in pages served by our Moodle-based VLE, OpenLearn and a lot of Drupal-powered sites. And it must not degrade the user-experience where its embedded.
A key differentiator for CodeIgniter and Drupal is, by default Drupal stores all its configuration, including page routing in a database, while CodeIgniter stores its configuration in PHP scripts. For a typical content-based site, Drupal can offer great flexibility. However for a web service, which as we have discussed would only use a few parts of Drupal this is a definite cost.
Checking which modules are enabled, and performing page routing using Drupal menus would presumably necessitate at least two database queries, maybe more. And this is before you have factored in queries that are specific to the OU player application.
By contrast, in CodeIgniter you have fine-grained control over each database query. And if your application is simply a front-end to other web services/ data feeds - which the OU player may become - why, you can disable the database layer entirely.
Installation and configuration
Drupal includes an installer to create the necessary database tables. Following installation there is often a period of manual configuration using Drupal’s extensive administration interface. This involves enabling and disabling core and third-party modules, enabling a theme and so on. Alternatively, a bare database, containing the configuration but no content could be packaged as part of the installation.
CodeIgniter stores its configuration in PHP scripts, and is more closely tied to the specific application. So the amount of configuration can be minimized. This simplifies configuration, making it easier to document and easier for a third party to install.
At least as far back as CodeIgniter 1.7 (and the OU player use CI 2.0), CodeIgniter’s database abstraction layer has contained drivers for MySQL, PostgreSQL, MSSQL, Oracle, ODBC and sqllite (drivers in the CodeIgniter-reactor repository on Bitbucket).
In contrast, the database abstraction layer in Drupal 6 only appears to work with MySQL and PostgreSQL, with caveats documented for Postgres (http://drupal.org/requirements#database). Drupal 7 adds support for MSSQL, SQL light and Oracle, primarily via third-party modules (http://drupal.org/project/sqlsrv).
As far as I know, at present our central IT service mostly supports Drupal 6-based sites (presumably there is a migration plan for Drupal 7, dependent on support for the OU’s supported list of third-party modules). And yet central IT is trying to discourage the use of MySQL - favouring MSSQL and Oracle.
We already use it
We also use Drupal, for iSpot, OLnet (now maintained in KMi), DISCO, our internal bug/issue tracker, IET-public (hosted by central IT), the IET intranet, and we have plans to use Drupal for a number of new/ re-worked web sites.
In this article we have seen how the OU player benefits from using a low-level framework such as CodeIgniter. If implemented in Drupal, the player would not take advantage of many of the benefits of Drupal, and would be subject to a number of the dis-advantages.
It is in all our interests to not have a proliferation of technologies that need ongoing maintenance and support. At the same time though, there will be cases like the OU player where fine-grained and low-level control is needed.
The approach we are adopting in IET is to use Drupal where possible for straightforward content-driven sites. For projects where we want more fine-grained control, particularly over social functionality (eg. Cloudworks), or Drupal is not a good fit (OU player) we use a low-level framework.
(Draft blog post, 14 August.)