On Mon, Nov 03, 2003 at 11:01:54AM -0500, Dossy wrote: > On 2003.11.02, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
> 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 Well now, that depends, doesn't it? I'm not really familiar with how AOLservers HTTP processing works underneath (the C code, and how things changed from 3.x to 4.0, for example), that part has just worked out of the box for me, for my needs. (E.g., I have never been responsibly for tuning an extrememly large and busy site.) But I can attest from personal experience that AOLserver work quite nicely as the former, a "general purpose, multi-threaded daemon with a Tcl interpreter that ... happens to come standard with an HTTP request processor." I'd suggest that the later (web serving) is AOLserver's primary role, but the former (general purpose serving) is a second job that it's also very good at. I don't really see any conflict between the two, either. 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. > that case, think about the 95% case for AOLserver -- serving an HTTP > request with NO authentication. In this scenario, supporting N > 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. Whether or not that minimal auth support it is a problem that needs solving, and how, is a different question - see below. > > Bottom line (for me): If people are happy with tossing in a custom > > Tcl layer atop of AS everytime they need to overcome some internal > > "limitations", this is ok for me. But this is bad for the AS itself. > Come on, now. You're just being antagonistic, now. This is like > saying, "If folks feel they need to run ACS or OpenACS to get more > functionality than comes stock with the AOLserver distribution, this is > bad for AOLserver." 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. 2. The basic HTTP authentication built into AOLserver is simply a special purpose hack. It's ok that it's present in AOLserver, 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. 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. :) 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've done a small bit of this myself, but as with all re-factoring and productizing, it can be quite a lot of work (remember Brooks), and the people working on the OpenACS code don't have a lot of insentive to do it, because of course MOST of their web project DO use all of OpenACS, not just AOLserver alone. Of course, if several NEW people volunteered to work on OpenACS solely to help make things more functionality useful to other users of AOLserver, while not making anything any worse for the current users of OpenACS, then that would be an entirely different story. > far from being feature-complete, but it's a lot further along. Why? "Further along" in what specific way? Market share? Or actual utility for a given engineer implementing things with? These two criteria are related (over time anyway), but quite distinct. If they were NOT distinct presumably we would all be using Apache/PHP instead of AOLserver... -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com -- 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.
