.LRN Technology Choices Explained
We are often asked about the underlying technology for .LRN and why we use it instead of other tools.
First, to recap, .LRN runs on a technology stack that includes:
- one of a number of UNIX variants as the operating system. These include Linux, FreeBSD, Solaris, HP/UX, etc.
- a choice of Oracle or Postgres as the RDBMS
- AOLServer as the application/ web server
- Tcl as the language in which "application logic" is implemented
We rely on UNIX because it is more reliable than Windows, doesn't constrain our choices higher in the technology stack as much, and because there are open-source variants available.
We rely on Oracle or Postgres because these have been enterprise-class tools for much longer than either SQLServer (which only runs on Windows in any event) or MySQL. While MySQL is more popular due to the large number of smaller websites that use it, it has only recently become ACID-compliant (essential for any enterprise-class application) and has done so through the addition of non-native components that are not as widely used and incompletely implemented (e.g., InnoDB for row-level table-locking). Postgres is popular enough in any event on its own, so much so that it is commercially supported (http://sources.redhat.com/rhdb/)
Here are some helpful documents evaluating Postgres and MySQL together:
- http://www.devx.com/dbzone/Article/20743
- http://www.webtechniques.com/archives/2001/09/jepson/
We use AOLServer instead of Apache because AOLServer performs better and is better supported for the large-scale production sites that .LRN
typically runs.
Some history: AOLServer was originally developed as a commercial application by a company called NaviServer. After its own careful
evaluation of NaviServer versus Apache and other options, AOL bought
NaviServer (the company) in the mid 1990's to run its flagship sites, such as AOL.com and Mapquest. AOL subsequently decided to distribute NaviServer as open-source software under the GPL, and still runs its major sites on AOLServer(see http://uptime.netcraft.com/up/graph/?host=aol.com).
AOLServer's superior performance is based in part on multithreading
capability developed in 1994 that Apache has only recently begun to
support in version 2.0, which is an extensive rewrite of the 1.x
versions that most Apache users and developers are more familiar with.
See http://www.pcworld.com/news/article/0,aid,93484,tk,dn040902X,00.asp
for more details.
Apache, as many people know, consists of a relatively thin "core" and a
series of "mods" that extend it. So while "core" Apache and a standard
set of mods may be popular, mods that support unique needs
high-performance applications are less widely used and have fewer
developers qualified to support them. As a result it can be misleading
to say that Apache is more popular than AOLServer for high-performance
applications, because it really depends on what Apache mods are being
used.
A common objection is that Apache is much more widely used than AOLServer. We suggest that comparing Apache market share to AOLServer market share is not useful.
Both Apache and AOLServer provide http listeners/ web servers, which are mature and well-understood technologies and not typically customized by different organizations in any event. If for whatever reason an organization is more comfortable with Apache as its web server, Apache can be run in front of AOLServer via reverse proxy.
Apache and AOLServer also provide application server capabilities for different programming languages. An application server consists of 1) either an interpreter for scripting languages like Perl, Tcl, PHP, Python, etc., or a compiler for languages like Java and .NET, plus 2) libraries of pre-built procedures that can be called by a program like .LRN. (While Apache and AOLServer support them, compiled languages like Java are typically run with external application servers like Tomcat).
The relevant comparison would be *the share of each unique application server/ programming language combination, in each distinct market segment*. This is because we care about how extensive -- and extensively used -- the libraries for each specific app server + programming language combination are. These libraries tend to be used more extensively for more complex applications supporting larger production implementations. So just because Apache is used more widely than AOLServer doesn't mean that more engineers are familiar with the full set of components required to support a production-class implementation -- or even that such components exist. For example, even with all its mods, Apache still doesn't have a built-in scheduler. Apache programmers are forced to write cron jobs that have no access to Apache's memory.
So, when the issue is viewed this way, the Apache vs. AOLServer share advantage, *for enterprise-class deployments*, is likely quite a bit less.
The choice of Tcl over, say, PHP for "application logic" is a detail.
Both are very simple and easy to learn (PHP stands for "Personal Home
Pages" after all). Tcl was selected over PHP because it is more mature
and is the best-supported language in AOLServer (most extensive
procedure library, and a native Tcl interpreter for maximum
performance). Also, PHP is not yet well-supported in Apache 2.0 (see
http://www.zend.com/whitepapers/PHPandApache2-ZendWhitepaper.pdf).
The choice of a scripting language like Tcl over object-oriented tools
like java and .NET's C# is based on the ease and speed of development
with scripting tools, which are easier to learn and don't require
re-compiling when changes are made (the browser is the IDE with
scripting tools). But any software engineer competent enough to work
with a complex enterprise-class application will find Tcl easy enough to be fully productive with in no more than a couple of days.
The choice of technologies should be secondary to the choice of
application. The first and most important question any potential
customer for an enterprise-class application like .LRN should ask is,
"how close is the functional fit to what I need to start with?". Next,
a customer should ask, "how sophisticated and well-documented are the
API's for extending the application to get what I need?". Third, the
customer should ask: "who else uses this application, and for what?"
(many tools are downloaded often, and there are plenty of small and
experimental installations of them, but very few support thousands or
tens of thousands of users). Fourth, a customer should find out from
these users how expensive and complex it has been to customize, deploy,
and maintain. The answers to these questions are *much* more important
than the choices of underlying technologies, as long as those underlying technologies have a critical mass of adoption, as .LRN does, to insure their continued development and maintenance.
