Hey Dossy and Everyone else! I think it is great to ask for and encourage inprovements to the AOLserver website and community involvement.
Here are my suggestions: 1. Ditch non-AOLserver technology. If it doesn't run under AOLserver, replace it with something that does. If the AOLserver community cannot figure out collectively how to assemble a website from their own software, what wider audience are you really looking for? This does not mean that source code should be removed from SF, just the AOLserver website and everything else unrelated to cvs. 2. Expose real world examples, and code examples. Without even the simplist Tutorial, newbies will simply look elsewhere for their webserver. Unfortunately these real world examples should include technology that some of us consider sub-par: A. CGI integration --For example I got sql-ledger running very easily ( a perl cgi module) B. Basic Authentication -- Some of this is currently broken. I had to add some C code just to get it to work again. Some simple sites need nothing more than this. C. Working examples of database integration, expecially ODBC and if possible MySQL. ------ Other examples are mentioned as foreign: OACS, for instance. Note that ACS, and OACS are responsible for a large percentage of users, and these projects contributed the oracle driver and the postgres driver. AOL itself has done nothing to advance database integration, and the base nsdb module remains incomplete. If these drivers didn't exist, my interest in this project would be zero (0). 3. Provide configuration examples. Some things are needed just for sanity. We don't have an _AOLserver 4.x the Definitive Guide_, which means there is a lot of configuration information buried in the C code. I just spent a few days going through all the core code to pull out every config parameter. In order to allow AOLserver to be more self-documenting, I suggest a slight change to the way AOLserver starts up. At the moment, modules look through the config ns_sets to find values. If they don't find a value, they use a default. The default is buried in C code and is impossible to find after the server starts up. The small change would be to have the procedure which checks for the value (and doesn't find one), to _add_ the default to the config ns_set. This would allow admins to always find what defaults are set (and what config parameters are available), after the server is running. Other methods of self-documentation should be explored. 4. Ditch the AOL moniker. EVERY person I tell about what software I use is CONFUSED by this. Words have meaning and AOL doesn't really have a place in the webserver software area. It just doesn't connect. AOL is a service provider, not a software company. Ummm, the change might also send a subtle message to everyone else here that this project is more than an AOL lapdog. 5. Show us how the nsjk2 thing is supposed to work. It appears to me, via nonreflective observation that AOL is skipping further development of AOLserver in favor of using java technology. Good or bad, how is AOL using this component, and why? If the largest user of AOLserver can't reveal some of their reasoning, and best practices, any suggestions by the greater community will be useless. The train can only go in one direction at a time. Since AOL is defacto in charge of the controls, and an itinerary might help others follow along. 6. Split the discussion between C level source code and applications. A. Dossy was quoted as saying that AOL provides most of the developer talent to the AOLserver project. <http://www.internetnews.com/dev-news/article.php/3462701> This is actually very untrue when you consider applications. AOL has released C level modules, but has done _almost nothing_ in regards to demonstrating how to use AOLserver in a production environment, or how to develop applications. Maybe they consider this a trade secret? But for whatever reason, AOL has not contributed very much to an area that will attract 99% of new users (that is application developers). If you want to attract C code developers, the job will be very difficult. First, the code is very mature and in very good shape. Lacking is only a little bit of documentation. Any changes to this code are best handled by dedicated, and very experienced developers, which AOL already employs. If documentation is the issue, it really should be left, and maybe required, of those who actually write, and work with the code. I would argue that none of this C level work will attract even a single new user to the AOLserver project. Another problem is the persistence of bugs. If they are not on AOL's list, they usually don't get addressed. Recently there was a claim of a memory leak bug. The discussion went on for quite a while. Why not just provide a guide to finding and tracking memory leaks? How do you figure out if the leak is in core, or in a client module? The strangest part of the discussion was a claim that the leak couldn't be in core, and then a statement that merely setting connsperthread > 0 produces a memory leak. What is strange about this is that the source code identifies the connsperthread option as being designed to work around memory leaks in client code by occasionally dropping a thread. Am I the only one who sees the irony of all this? B. Application level discussion and support. Dudes, this is what people are looking for, at least the ones which have a life. I don't, so the current AOLserver project agrees with me just fine. Again, the big silent voice of experience is AOL. Really does anyone care that half the world's web content is served via AOLserver, if we don't know how it is done? Do we care that AOLserver is massively scaleable if we don't know how? The rest of the community is a series of satelite projects, some open, some closed, all developing their own style. Possibly the real beauty of AOLserver is how easy it is to do you own thing. For instance, I just reviewed ASP.NET, and it is truly amazing what a disaster that is. You either use their ill conceived paradigm, or pay a huge development time penalty to work around their strategy. However, I have to admit, at least simple things are simple, and they have VAST, though meaningless, tutorials on how the basics work. Again, I must say that I find it frustrating that the leading web technology company, AOL, is so silent on these matters. Until we get a good explanation of _exactly why and how_ AOL uses AOLserver, I doubt any other reasonable sized enterprise would risk using this technology. 7. Release more code. For a specific example of what I am talking about, consider the NV: network variable. For _years_ I have been inquiring about NVs, since Jim Davidson mentioned that they are used by AOL. An NV is simply shared data, available to multiple physical servers, a networked nsv, I suppose, but maybe more. This would serve the same essential purpose of a javabean I think. But has anything come from my requests? Of course not. This applies many times over to application code, and development styles. AOLserver doesn't come with a development framework. It is wide open, but developers have to start from scratch, with not much direction on what needs to be developed and how. It is not obvious that if you have a medium to large project that AOLserver is the platform you should use. 8. Receptive to junior developers. For those who have never contributed C code, or patches, a small example of the difficulty of doing it might help explain the situation. At one time I was on the Core Committee. I noticed that AOLserver mishandled the -g command line switch. Depending on the setup, you could even specify any group, even if the user specified by -u wasn't in that group (including root!). I submitted a patch, and a few new apis to handle the -g switch correctly and make sure the user was in the group specified (and the root group wasn't used). Instead of accepting the patch, it was rejected due to formatting errors. I was directed to the style guide. Although I never discovered what errors I had made in style, I did notice the many already existing violations in the unpatched code. 9. Given all of the above, I don't find it too surprising that developers have asked for financial assistance to handle almost meaningless chores of documenting other (paid) peoples' code, or designing a website for the largest (for-profit) ISP/Media-Giant on the planet. tom jackson -- 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.
