Now, a lot of you may be curious why on earth I would write an article about the merits of anything containing the letters “AOL” in it. In my job, I write software primarly for use on a webserver running AOLServer 4.0x. I know this is already casting a large number of doubts in your mind, but let me finish.

AOLServer was not written by AOL, but is used by them (and I believe it was purchased by them way back when.) It has many pros and a few cons. I will try to discuss those, so that anyone in the market for an application server/web server can make an educated decision about it.

First off, most of these points were stolen directly from Philip Greenspun, but they were all things I was thinking anyways. Please visit his page for a more detailed explanation…

Pros:

• Fast. AOLServer is designed to be very fast, as it has a Tcl interpreter built into the server. The Tcl language is well developed and easy to find information and help on.
• Scaleable. The software was primarily designed to serve a single application on an enormous scale. It has built in session management and is well designed to spread across many servers.
• Pooled Database Connections. Instead of opening hundreds of connections to your database servers, AOLServer manages the pooling internally. This is very helpful when you have a very busy or very large application, as the memory footprint is very light.
• Extensible. There is a lot of available open-source libraries for doing lots of sophisticated things, such as building CRMs, ecommerce sites, etc., as well as extending AOLServer to run php, python, and other languages.
• Elimination of Spaghetti code. While it is possible to do inline scripting in AOLServer, the basic model is to have a .tcl file containing the logic, and a .adp template containing the presentation layer. This makes things very nice for working with your existing code.
• Maintainability. A very large number of functions are available in the server, so many applications use the same high-level function calls. This makes the code much easier to maintain as not as many custom functions need to be written and regression tested.
• Built in support for cURL-like features. This is new in Tcl 8.5, but there is a module called http which can be used to perform screen scraping or rss aggregation or <insert your own raw socket use here>

Cons:

• Weak support for hosting multiple domains. This server is designed around a single application of very large scale. If you are a hosting company, you are probably better off using Apache or IIS, which are designed to manage lots of small sites, and there is a plethora of tools for automating this process.
• No direct support for PHP and other languages commonly used for web design. Although there is many libraries to overcome this limitation, it will take a little tinkering to get them working. You cannot directly port a website from php to run on AOLServer for example.
• Relatively small community of experts. While there is a lot of valuable information, the community developing in Tcl is relatively small, so it will often take a bit of searching to find answers to complex questions.
• Non-typed variables. All variables in Tcl are Strings. This might be considered both a Pro and a Con, however I have found it to be more of a con than not. There is workarounds, but Tcl still handles conversion of numbers with leading 0s poorly. This is fixable with code.