First there was a company called NaviSoft founded by a couple of wizard Unix programmers. They've set out to create the best web publishing system on the planet and they were well on their way. It was 1994 and their product, a web server called NaviServer, was multi-threaded from the ground up (Apache is still trying to catch up with this particular feature), had a tightly integrated scripting language, good extension API and database connectivity built in. It was so good that AOL decided in 1996 to use it to power the core of their business - multiple AOL web-estate. But buying programs is not how AOL works - they've bought the whole company to make sure that the software will grow as fast as AOL's needs. Thus NaviServer has been renamed to AOLserver. In 1999 an MIT researcher, accomplished photographer and web-developer in one person, Philip Greenspun, convinced AOL that it should open-source AOLserver for the mutual benefit of AOL and public at large. So they did. After a few months of frantic code cleanup AOLserver 3.0 debuted as an open-source web server whose development is largely community driven. AOLserver 3.1 has been released in September 2000.
AOLserver is robust, stable and scalable, after all it has been perfected for years by a tight group of programming wizards. Fortunately, you don't have to take my word for it. AOLserver has been battle-field tested in the most demanding environments. It is known to serve 30 thousand hits per seconds on AOL sites. ArsDigita, a Web development company, has built numerous web sites (www.photo.net, www.scorecard.com, www.away.com) that routinely serve millions hits per day. The bottom line is: AOLserver proved to be extremely stable and scalable by serving some of the most popular sites on the Internet today.
You want web server to support four of the most popular programming paradigms. You can think of a web service in object-oriented terms: a web server is an object whose methods are URLs. Users invoke methods by requesting an URL from within their web browser. The simplest way a web server can respond to such request is to fetch a static HTML file from the file system and send its content to an user. Doing anything more complicated means running a computer program which will generate an HTML page. One way to do it is by extending web server itself using its C extension API. Every popular web server (Apache, IIS, Netscape) has some implementation of this idea. AOLserver provides well thought out C extension API that makes writing modules that extend its functionality really easy. As an example: the source code embedding PHP in AOLserver is half the size of the similar code that embeds PHP in Apache (this "benchmark" should be taken with an appropriate grain of salt but it gives a rough idea of extension API quality). Having praised the API it should be noted that this is a very slow and error prone way of writing web services (on any web server). You have to code in a very low-level language (C), debugging is a nightmare and smallest mistake can crash the whole server.
To remedy those shortcomings a CGI protocol has been created. This protocol is supported by all major web servers including AOLserver. The idea is very simple: upon page request a web server will execute a program and whatever this program will send to its standard output will be sent back to a browser. The greatest advantage is that it can significantly shorten development time since programmer can use the best tool for the job (which usually means a scripting language like Perl, Tcl, Lisp or simply a language that he is most familiar with). The disadvantage is that it's slow (for each request a program needs to be executed and it's very expensive operation) and thus doesn't scale well.
To improve performance web servers started to directly embed scripting languages. The most popular examples are mod_perl in Apache and PHP. Since interpreter is linked with the web server executable it's no longer necessary to fork an external program to execute the script which saves a lot of time. This approach conserves the fast development advantage of CGI scripts but the cost is that it limits you to one particular scripting language (which may or may not be an disadvantage depending on how well developer knows this scripting language). AOLserver's story in this department is very compelling: it is the only major web server that comes with a tightly integrated scripting language (Tcl) out-of-the-box. If for some reason you dislike Tcl you can use PHP, Python, Java (and there is a work in progress to add Perl support).
The last programming paradigm is server-side includes ie. code embedded in HTML pages. When a page is server it is parsed by the server, HTML code is left untouched, embedded code chunks are executed and replaced by their output and resulting page is sent to browser. The most popular example of this paradigm are ASP pages in IIS. AOLserver provides developers with a similar feature: ADP pages that allows you to embeded Tcl code inside HTML.
You want your web service to be fast and efficient. AOLserver's multi-threaded architecture gives you the performance advantage over process based web servers (eg. Apache 1.3.x, Apache 2.0 is being rewritten as multi-threaded server but hasn't yet reached maturity). If a web server is based on processes it has to create a new process to serve each http request. AOLserver only has to spawn a new thread and it's much faster.
You want to have ability to share data between scripts. There are many uses for such feature, the simplest example would be to count how many times a given page/script has been called. It's not easy to achieve this in a process based web server because processes do not share dynamically allocated memory. As an example, if you use mod_perl scripts in Apache, you can have a global variable and increment it but if you think that this will tell you the total number of times the script has been executed you're in for a surprise: this value is actually per-script-per-process and since Apache pre-forks multiple processes and (as far as programmer is concerned) unpredictably assigns them to execute scripts your counter won't give you an accurate number. It's possible to overcome this using shared memory (or by storing the data in a database) but it is so cumbersome and non-standard that it's not popular among Apache developers. In AOLserver it's a child's play thanks to the fact that threads share dynamic memory and excellent built-in nsv interface.
Since dynamic web services usually have to store
data in a database and retrieve data from a databases you
want your web server to have an
ability to talk to databases. AOLserver comes
with an exceptionally good, standardized and fast database
connectivity API. It's fast because it uses connection pooling, ie.
database connections are opened when the web server starts and
subsequently reused among scripts.
An alternative (used eg. in PHP3) is to open a connection
on the beginning of a script and close it at the end.
This approach is much slower.
Standardized means that you use the same API to send SQL commands regardless of the database server used (to contrast, in PHP each database has its own set of APIs). It's easier to port the code when switching databases (SQL statements still need to be ported, but that just shows how standard an SQL standard is).
To top it off drivers exist for most popular databases: Oracle, PostgreSQL, MySQL, Informix, Interbase, Solid, DB2.
AOLserver provides developers with more basic blocks for building dynamic web services than any other web server. Most web services have to solve many similar problems and provide:
To get more information check those sites: