Forum .LRN Q&A: ".LRN Technology Choices Explained" -- feedback requested on this draft

.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 (

    Here are some helpful documents evaluating Postgres and MySQL together:

    • 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 and Mapquest. AOL subsequently decided to distribute NaviServer as open-source software under the GPL, and still runs its major sites on AOLServer(see

      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,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

      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.

After a quick read, everything sounds fine, and elegant. This kind of document has been needed for a long time, so has been a great progress.

For the last paragraph, do you have the answers to that questions?

For documented, my opinion is that we have a good documentation but not complete, specially when someone wants to start to play with .LRN and customize for its own need. Some sort of self learning / code research always happen, and that's one of the thing we want to address at e-lane in the next year (around march 05).

For sophisticated, yes, indeed, we are sophisticated (though that word can mean to many things, but sounds good =), specially when you start to see a lot of dummy implementations (php) or too complicated ones (java).

Probably we'll need a detailed list of functionalities, isn't it?

I know the consortium did a survey to known users, so data will come.

A more detailed list of .LRN / OACS features can be found in the whitepaper on .LRN, now available at

Documentation, including documentation of APIs for developers, can be found at

The six case studies on the .LRN site provide examples of who is using .LRN and how.

The MIT Sloan case study gives a good sense of overall cost of ownership:

I hope this helps! Thanks for the feedback...

I don't know. There are some major holes in this document. I read it as a very defensive positioning of .LRN, and not very effective at that. It also reads as a collection of notes pulled together in a haphazard manner.

IMO, it reads as a very poor technical position paper written by someone nontechnical. The arguments used were true at the time that ACS was done, but not very true now. For example, one of the articles referenced is from 2001!

I don't think it's terribly well organized. If the goal is to convince the client that OpenACS fits their needs, why not lead with the last paragraph and frame the discussion in that context? "These are the questions you need to consider and this is why .LRN is a good fit."

An argument /can't/ be won taking on PHP, Java, .NET and Apache head on.

For instance, "We use AOLServer instead of Apache because AOLServer performs better and is better supported for the large-scale production sites that .LRN typically runs."

It's totally false that Apache can't handle a site as large as .LRN installations are. People have built larger systems with Apache plenty of times. Bringing up Apache in this context sets up the whole gig for getting knocked down very easily.

Rather than obsess about what is popular, why not extol the virtues of the tools that we have?

A better approach would be "We love AOLserver because A, B and C. It compares favorably to Apache with regards to X, Y and Z."

Maybe it's just late and I'm being cranky, but I really don't think this is a very effective piece of literature. There is a good bit of information in this document that can be formed into a properly convincing paper, though.


I agree with Talli that the document is a bit on the defensive side. It is questionable if arguing that Apache/PHP are not extensively used, not mature, or somehow technically inferior will fly with a lot of people. Above all I think the truth of such claims is questionable.

It would be better to argue for the .LRN technology stack by showing its successful track record. AOLserver/Tcl is a productive and proven technology that gets the job done, and from a programmer perspective, working with it is very similar to working with Apache/PHP.

I think some context here might help.  This article was written in response to a request from a community member who runs IT for a large institution.  I was trying to help him respond to a review of .LRN's architecture that was prepared by people who were evaluating this community member's application for a sizable grant.

The review of .LRN's architecture criticized .LRN for using AOLServer instead of Apache, and for using Tcl instead of PHP, among other things.  So the defensive tone directly reflects the need of this document to address the "why not LAMP?" question.  Ignoring the critique was not an option in this case.

I think some may have mis-interpreted what I tried to convey about AOLServer vs. Apache (so the fault is mine and I need to be more clear).  The point I'm making is that to say that Apache's worldwide share of the web server market is 63% while AOLServer's is much smaller is a misleading comparison.  Many more people drive cars than heavy-duty trucks.  A more appropriate comparison is the number of "Apache-brand" heavy-duty trucks versus "AOLServer-brand" trucks, based on each's associated capabilities and operators.  It's not to say that AOLServer/Tcl is superior across the board to Apache/PHP for high-end applications.  It *is* to say that AOLServer compares more favorably than the superficial market share statistics suggest, as reasoned in the article.

With this post I invite the community member mentioned above to share the critique if appropriate.  I also encourage the community to help him more effectively than I have.  My request for feedback, in the form of alternative text that improves on what I have posted here, remains open --  in the spirit of a "non-technical" person who posts here to learn and improve his work with the help of more "technical" people.

Who did this "architectural review" of dotLRN? If he more or less baldly said, "Using Tcl is bad, use PHP instead.", then he clearly isn't competent to review anything - but perhaps that was not the gist of his actual review.
Hi, Cesar.
I'm writing a paper about an adaptive application using .LRN. The information published in your post is useful to me but it is outdated. I wonder if you have the current information.
Thank you very much.

Thanks for your message. I'll defer to other community members to respond, as I do not personally have updated documentation. You might start here though: .


and this:

might also be useful.

Good Luck,

Cesar Brea