Moodle architecture
From a system administrator's perspective, Moodle has been designed according to the following criteria:
Moodle should run on the widest variety of platforms
The web application platform that runs on most platforms is PHP combined with MySQL, and this is the environment that Moodle has been developed in (on Linux, Windows, and Mac OS X). Moodle also uses the ADOdb library for database abstraction, which means Moodle can use more than ten different brands of database (unfortunately, though, it can not yet set up tables in all these databases - more on this later).
Moodle should be easy to install, learn and modify
Early prototypes of Moodle (1999) were built using Zope - an advanced object-oriented web application server. Unfortunately I found that although the technology was pretty cool, it had a very steep learning curve and was not very flexible in terms of system administration. The PHP scripting language, on the other hand, is very easy to get into (especially if you've done any programming using any other scripting language). Early on I made the decision to avoid using a class-oriented design - again, to keep it simple to understand for novices. Code reuse is instead achieved by libraries of clearly-named functions and consistent layout of script files. PHP is also easy to install (binaries are available for every platform) and is widely available to the point that most web hosting services provide it as standard.
It should be easy to upgrade from one version to the next
Moodle knows what version it is (as well as the versions of all plug-in modules) and a mechanism has been built-in so that Moodle can properly upgrade itself to new versions (for example it can rename database tables or add new fields). If using CVS in Unix for example, one can just do a "cvs update -d" and then visit the site home page to complete an upgrade.
It should be modular to allow for growth
Moodle has a number of features that are modular, including themes, activities, interface languages, database schemas and course formats. This allows anyone to add features to the main codebase or to even distribute them separately. More on this below in the next section.
It should be able to be used in conjunction with other systems
One thing Moodle does is keep all files for one course within a single, normal directory on the server. This would allow a system administrator to provide seamless forms of file-level access for each teacher, such as Appletalk, SMB, NFS, FTP, WebDAV and so on. The authentication modules allow Moodle to use LDAP, IMAP, POP3, NNTP and other databases as sources for user information. Otherwise, there is work yet to do. Features planned for Moodle in future versions include: import and export of Moodle data using XML-based formats (including IMS and SCORM); and increased use of style sheets for interface formatting (so that it can be integrated visually into other web sites).
It should have precisly defined import and export structures
It should be easy for a person to import and export data to Moodle. All imports and exports should use open file format standards such as XML and these XML files should be well-documented. Ideally we should provide XML Schems for each exchange document and the XML Schems should only used data elements that have precise definitions in a central metadata registry.
