I'm pretty new to AOLserver and so I'm by no mean an expert on AOLserver itself, but I have got plenty of experience in the internet world, in particular running high traffic portals.
I was drawn to AOLserver for a few reasons: 1) I love Tcl 2) Having used the (Tcl based) Vignette CMS I wanted to see just how terribly slow Vignette was 3) I needed a cheap (or free) application server for a project I was working on, one that I could setup, configure and code for quickly and easily and one that would scale at a later date. AOLserver turned out to be a very capable beast, but the experience for a newbie is not incredibly enjoyable. The community *is* one of the most friendly and helpful that I've come across, which make this experience bearable, but AOLserver really is lacking example (or working) code that would help a new user build something real, rather than just serve a few random web pages. The documentation isn't really at fault as you can find information on pretty much every configurable option, but there's very little information on the *best* way to configure the server for different common uses. (e.g. simple error handling using startpage.adp and errorpage.adp - you are told it can be done, but there's little or no information on how you might usefully use this feature) There's a number of modules out there that are in varying states of release - I've lost count of how many pure Tcl, pure C or hybrid session management modules I found, before deciding to refactor the OpenACS version. There's little information on how to develop for, support and and maintain an AOLserver site e.g. tracking down bits of code that performance bottlenecks etc. I'm sure there's reams of this kicking around at AOL, and other live sites, and it owuld be invaluable to the new user (and probably to the commuity) for these to be made available. Compare this with other systems (OpenACS incldued) where there's more or less complete working solutions for many common website features that you can just download and install and have them up and running (not necesarily optimally) in minutes. > > Before we continue this thought, lets step back a second. > Is AOLserver > > a general purpose, multi-threaded daemon with a Tcl interpreter that > > just /coincidentally/ happens to come standard with an HTTP request > > processor ... or is AOLserver a specialized application built > > specifically for the fast delivery of dynamic web pages, using a > > multi-threaded Tcl page generation engine? > > > > I hope you'll agree that the latter is true, and not the former. In > The answer to that will vary depending on how someone is using it - not everyone will have used AOLserver enough, or have looked into the code enough to answer with any authority. As far as I can see, if you believe the stats, the AOLserver *is* an extremely performant scalable HTTP server. Being a multithreaded app rather than a multiprocess (a la Apache 1.x) is a good thing in this environment. However, there is little information from the sites where AOLserver is really hammered on how they've done this i.e. how they have set up farms of servers, how they balance incoming requests over them, how they measure performance of both static files and dynamically generated output. > To the extent that AOLserver can be improved to better support the > "general daemon" role without hurting the "web server" role, doing so > is clearly a Good Thing. I'd agree with this, emphasizing the *without* bit though! The authors of things like nsdns, nssnmp etc. would probably argue that AOLserver *is* a very good multipurpose server. > > Authentication being hard-wired in C and very lightweight (only > > supporting Basic auth) makes sense, because authentication > checks could > > potentially have to be performed for EVERY single HTTP > request -- if it > > weren't lightweight and wired in C, there could be risk of > performance > > loss at the auth layer. > > Nonsense. If that were true OpenACS never would have implemented it's > extensive user authentication and session tracking via Tcl, cookies, > the RDBMS, and registered filters. Clearly for a large class of > AOLserver users, the "hard-wired" authentication support in AOLserver > was so minimal as to be utterly useless. Not necessarily - may people for purely asthetic reasons don't like having the browser 'pop-up' the login box and prefer to embed this in a page that fits in their site nicely. I can't speak for OpenACS of course but this could have been a consideration. They could have easily taken the nsperm code and modified this to use info from the database but I suspect that they had a preference to do everything in Tcl to make OpenACS more 'open' - to extend it and modify it you only need know Tcl (not Tcl *and* C) > Whether or not that minimal auth support it is a problem that needs > solving, and how, is a different question - see below. At what point does a web server stop being a webserver when it doesn't support everything in the HTTP standard? I'd personally say the more of the HTTP1.0 and HTTP1.1 standards that AOLserver supports the less people will reject it for non-compliance. > No, I think Zoran had a good point. One of AOLserver's major > strengths is the flexibility and power that it's clean design > provides. (Arguably, it's kind of like a microkernel OS for web > apps...) We are all at least somewhat familiar with how AOLserver > goes about doing this (registered filters, Tcl and C APIs, etc.) > > However, to the extent that OpenACS had to roll all their own > authentication using registered filters BECAUSE the existing plugins > or callbacks for authentication already present in AOLserver were half > done or incomplete, or DESPITE the existence of those functions, then > yes that IS a negative for AOLserver. It says roughly one of these > these 3 things about AOLserver's authentication support: > > 1. OpenACS implementing all authentication via registered filters was > GOOD, it was an example of the best approach for authentication > overall. Authentication doesn't belong in the AOLserver core at all, > it should be implemented soley via registered filters, and any > existing partial and limited built-in authentication support should be > removed. If you remove all authentication from the core then you could argue that AOLserver is nolonger compliant with the HTTP standards. There are arguments for and against authentication being handled by the webserver or effectively the application (running on the application server). If people want to quickly passord protect a directory or two then the existing nsperm does the job. If people have a high traffic site where every user needs to log in, and they have lots of users registered then having to restart the server to update the user list is unacceptable - querying the database seems sensible, but can be prohibitvely slow when you have lots (100000+) of users - these queries slow down the whole system. Offloading the authentication to another server that is independent of the 'application' i.e. the website code is nice. Netscape/iPlanet allows the integration of the webserver with their (LDAP based) Directory Server which takes most of the authentication strain off the application server, and moves it onto a server tuned and optimized for this function. . 2. The basic HTTP authentication built into AOLserver is simply a > special purpose hack. It's ok that it's present in AOLserver, Definitely not the case! Basic authentication is part of the HTTP standard AOLserver should support it - name a webserver that doesn't! > but it > should be understood to be a historical, special purpose hack, and the > GENERAL solution for authentication should come via registered filters > as above. However, it would be nice if it were easier to a) use non-basic authentication methods b) write your own authentication code to query files, the database, an LDAP server, integrate with a SSO mechanism etc. > 3. Specific authentication callbacks in AOLserver make sense, are a > good idea, and should be provided and used in place of or in > combination with registered filters. Therefore, the existing > authentication callbacks and such are a good but incomplete; the > design and implementation needs to be finished. > > I have no idea which of those three is correct, but I'm curious to > hear what the rest of you think. :) my opinions above :-) > As an aside, there is quite a lot of code in OpenACS that is very > useful in general, and not especially specific to OpenACS at all. > E.g., the database API, the templating system, ad_proc and many of the > other Tcl APIs, and, of particular immediate interest here, the user > session authentication. > > It would be nice to re-factor much of that so it could be easily used > in non-OpenACS AOLserver environments as well. I agree completely with this. I've got a beta version of the OpenACS session management and authentiction code that works standalone in AOLserver without the need to install OpenACS. A few people on the list have expressed an interest so I'm about to pacakge this stuff up 'as is' and hopefully start some discussion on how to improve it. There's probably a handful of similar OpenACS 'features' that would be nice to have in standalone AOLserver, and would help both communities if they were 'disentangled' from OpenACS. This would require some help from the OpenACS community as it would clearly involve modification fo their code, but would make keeping any code dereived from OpenACS up to date much easier allowing both communities to benefit from its evolution. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
