The High Level Design of Oscailt

This document explains the basic design of the Oscailt IMC CMS, its key design goals and the overall architecture of the system.

1. Introduction

The Oscailt IMC CMS has grown over its lifespan from a set of web-scripts to a fully featured CMS. In doing so, a basic set of design goals and principles have provided guidance to the developers. First and foremost, Oscailt is designed to allow indymedia editors to do their job with as little pain as possible. Beyond that it aims to provide a similar function to any organisation or individual who wishes to avail of open publishing. It is 100% GPL.

2. Design Goals

2.1 Require a minimum of expertise in order to install and maintain it.

• Oscailt requires no rare libraries, no external software and no special configuration of your web server (beyond .htaccess files). It merely requires a standard PHP environment and runs on either unix or Windows based hosts. All of the functionality that oscailt supports is self-contained.
• Oscailt has a very simple three-click graphical install script.
• Oscailt works "out of the box". Although there are an enormous number of things that you can add on and fiddle with, the basic installation is ready to go as an IMC CMS within minutes
• Oscailt has proven very stable in practice. Indymedia Ireland has not had a known software-based crash in over 2 years. Anarkismo.net, http://www.anarkismo.net, has been running an alpha version of oscailt 3.0 since May 2005 with virtually no technical intervention.

2.2 Work on extremely limited resources

• Oscailt utilises several layers of caching in order to minimise database calls and speed up processing times
• Oscailt's object management engine basically "pre-compiles" the entire site into cached versions of the objects and only uses calls to highly optimised runtime objects at runtime.
• Indymedia Ireland, Oscailt's "flagship" site was serving up to 4 million requests a month at the time of writing (Aug 2005). This was on a sub $1000 dollar a year commercial shared hosting account. The average processing time to produce cached pages was in the order of 40 milliseconds. Non-cached pages generally took anything from 0.1 to 1 second to process. Tests indicate that Oscailt 3 should deliver comparable if slightly slower performance under heavy loads on tight resources.

2.3 Provide Features to support non-hierarchical, democratic, accountable and transparent modes of working

• There is no assumed hierarchical relationship among administrators and users in Oscailt's basic model
• Every administrative action produces a log record and can be configured to send a notification email to a emailing list. The notification process requires an editor to detail the reason for their actions. The Oscailt notification list, as well as the log (which can be made publically accessible) mean that oscailt can be configured to run in an entirely accountable way, without any need for extra work on the part of administrators.

2.4 Support true open publishing, anonymity of contributors and maximise user privacy

• Oscailt does not require users to register and does not normally retain any identifying information about people who publish information. IP addresses are only retained in special circumstances to identify the source of attacks on the site infrastructure. Despite this design limit, Oscailt provides a wealth of Anti-Abuse Defenses for the administrator.

2.5 Support true multi-lingual sites

• Oscailt 3.0's object management system is based on a language neutral xml data layer. This allows administrators to translate entire sites, including all layout elements. The entire site will then appear in the appropriate language for users.

2.6 Support large, dynamic teams of administrators who have varying degrees of trust towards each other

• Oscailt 3.0's user model is based on a Role Based Access Control model with a very fine-grained permission set for each role. You can give adminstrators the authority to do clearly defined tasks and no more.
• Oscailt allows administrators to divide their responsibilities across 'sections' of the site, each section's administration team can have whatever degree of autonomy from the rest is required.
• Oscailt-Community is an experimental research system which has been developed alongside oscailt 3.0. It replaces the hybrid RBAC-community model of Oscailt 3 with a pure native community policy based management system.

2.7 Enable clear organisation of information in a large, dynamic and evolving data set

• Oscailt content is classified in four dimensions (type, region, language, topic).
• Each data object can be configured to filter for any cross section of these four categories.
• Users can apply filters on any of these four categories within each object page.
• New topics, regions, filters and types can be created to demand
• Each object can apply filters to 'mask off' categories that are not relevant to it. So, for example, publish pages can be configured to only allow publication in a small set of topics.
• Any cross section of categories can be delegated to site sub-sections.

3. Fundamental Architecture

The Essential shape of Oscailt 3.0's architecture is shown in the image below.

As can be seen from the diagram above, the architecture is divided up into several different sub-systems. These sub-systems are the following.

1. Object Meta Data Management System
2. Front end URL translation and multi-lingual page composition
3. Optimised Runtime Display System

Meta Data Management System

The object metadata management system is the basic engine that allows oscailt to produce such flexible and dynamic output. It manages the relationships between objects, the linking between translations of objects, the updating of objects' metadata and the caching of objects. Since object configuration changes will always be much less frequent than simple user requests, the design of oscailt aimed to put as much of the functionality as was possible into this system. It is optimised for completeness rather than speed.

It produces cached versions of every object on the site. The 'displayable' objects - menus, pages, bars and inset boxes are specially cached to include cached versions of all their contained objects within their cache file. This limits the number of includes that are used at runtime as each page only has to include its menus, bars etc, the objects contained in these objects are contained within the cache files themselves.

The modules in the system are designed to produce as much static html as possible. Calls to the runtime system are only invoked where statically caching is impossible (due to automatic changes of contents such as in newswires). This is further explained in the Modules page add link. Suffice to say that Oscailt makes every attempt possible to limit the amount of code that is executed at runtime. The result of this is, on our test system (a shared commercial account under heavy load) object management actions can take a couple of seconds, page views often take as little as 0.1 seconds to process. This is an excellent distribution of processing resources.

Optimised Runtime Display System

The runtime display system is largely built around the oscailt 2.x objects. This is a collection of objects that represent the basic content elements in the system - such as the story object, the comment object, the story query object and so on. These objects use the new object hierarchy of display objects to integrate them into the object management system and to allow them to be easily expanded through the addition of new modules and new functionality. The core code is mostly stable, highly optimised and proven under high levels of traffic. The new display object hierarchy provides a wealth of functionality that makes extending the runtime system as easy as inheriting a class and overriding a couple of functions.

-- ChekovFeeney - 30 Aug 2005