Once mod_nsd 1.3 will be released, the 1.x version will be pretty much in maintenance mode. All new development effort was going to go to version 2.0 (for Apache 2.0), but there might be a better alternative.

Instead of building an Apache ns_* API compatibility layer, I will work on adding FastCGI support to AOLserver. A FastCGI-enabled AOLserver (or OpenNSD) process will behave *exactly* like a "normal" one (since it's the same source code), but will run a FastCGI listener instead of the HTTP one. This means that one can run applications written for the AOLserver API using any web server that supports FastCGI (like Apache, Zeus, IIS and iPlanet).

Comments?

Thanks for your comments.

I only worked with the Apache and Zeus FastCGI implementations so far. Apache's mod_fastcgi is written by the same guys who wrote the FastCGI spec, and it behaved very well for me in production (I used it with Zope). I only did a couple of quick tests with Zeus, but it looks like a solid one too. I don't know much about the state of FastCGI support for IIS and iPlanet.

Other things that talk FastCGI (this is not a complete list by any means):

• Zope has a FastCGI server integrated.
• WebWare has a FastCGI adapter (in the default distribution).
• PHP 4 has FastCGI support in it's SAPI (server API). A funny thing to note is that the Zeus folks did some tests with Zeus+PHP using ISAPI and Zeus+PHP using FastCGI, and they concluded that the FastCGI method is much more stable and robust (see http://support.zeus.com/products/php.html#isapi). Also, benchmarks done by them show that Zeus/FastCGI/PHP is significantly (26%) faster than Apache/mod_php.

For the AOLserver+FastCGI setup, AOLserver will be started by the user/admin/whatever, not by the web servers' FastCGI process manager.

The request path will look like this: the front-end web server (Apache, for example) gets and parses the requests, then sends it via FastCGI to AOLserver's request handling thread, from where it gets dispatched to one of the worker threads, then returned back to the web server.

talli

I am still interested to here what this buys you. What is the problem you are trying to solve? The unwritten assumption here is 'get rid of AOLserver', which is fine as far as I'm concerned, but that is not what you are doing. You are just ADDING another layer of complexity.

As far as implementation is concerned, it is not as easy as the existing nsvhr module. AOLserver supports socket drivers; nssock, nsssl, nsunix, but it does not support protocol drivers. You could write a socket driver which reconstructs the http request from the FastCGI stream and lets AOLserver parse it as normal, but it sounds a bit silly to me. In fact, it sounds like your writing a proxy server. It's been done.

Running two webserver is pointless unless you need the features of both at the same time, in which case run two webservers. If you can't afford a second IP address, run squid, mod_proxy or nsvhr, all of which are available right now and require no coding.

Do I smell a flame ? :) I hope not.

Thanks for the comments, Stephen. I have a couple things to address, though:

• On the technical side, the points made by Stephen are perfectly valid. It's not going to be as easy as nsvhr, because we need a protocol module and AOLserver doesn't have that, so patching in the core server will be needed. I will think of a way to do this as cleanly as possible.
• Using FastCGI instead of a proxy module in the other web server (because we're talking about using another web server, not about dedicated proxies like squid in reverse mode) has the advantage of being supported by a couple different web servers, and being lower overhead than a proxy.
• From an architectural point of view, this whole FastCGI stuff is silly indeed. As you said it, it remembers of buzzword compliance and three-tiered architectures.
• The most important thing is that the FastCGI interface is *not* for those who are already happily running AOLserver. The recommended way of running OpenACS will not change. The fact that AOLserver is a great web server will not change either. This whole "make it usable with Apache" thing is however a very popular request, because many people are reluctant to change their web server. I didn't believe it either, but then I realized that most of people I talked to about (Open)ACS -- even one of my consulting clients -- asked "what is AOLserver, I never heard of it". As Johnny Rocoo mentioned, there are quite a few downloads of the Apache RPMs, and even so I'm sure that at least half of the newbies that download it give up, because mod_nsd kind of sucks right now.
• Hosting. How many AOLserver hosting companies do you know? I know about 2, though let's suppose there are 5 and we don't know about them. Now, how many Apache hosting companies are there? A couple bazillions.
• Inclusion into distributions. OpenACS is not included in any distribution right now, exactly because it requires another web server in place of the carefully configured Apache that the vendor ships.
• Upgrade path. Suppose you're a newbie and you try out OpenACS, using Apache and AOLserver with FastCGI support. It's easy to setup, because you just grab a RPM and install it. After a while, you like OpenACS more and more and build a site with it. Eventually, you'll be willing to run AOLserver, but then all you need to do is change the AOLserver config file to disable the FastCGI stuff and enable the HTTP listener. Voila, you now have a fully working AOLserver with no FastCGI crap.

Putting aside the marketing issues for the moment (since this
particular person seemed comfortable with the separate ports
solution), are there any technical advantages to running the
OpenACS system through Apache rather than around it? Would it
make it any easier to start merging the two code bases in the
future, for example?

FastCGI sounds like it would be a very cool tool to have in one's AOLserver toolbox. But, I wonder about one thing - the tight integration of the AOLserver API. Would FastCGI allow the all of the ns_ API to work normally? I'm not sure, but presumably, AOLserver API calls like ns_conn could be properly implemented by having Apache (or whatever the main web sever is) pass the necessary information via environment variables or something to the AOLserver FastCGI process?

In other words, are the FastCGI spec and implementations powerful enough to allow the sort of tight API integration with the web server that has always been AOLserver's hallmark? From a brief look at www.fastcgi.com, I think the answer might be yes, but I'm not really sure.