On 2005.02.04, Tom Jackson <[EMAIL PROTECTED]> wrote: > 1. Ditch non-AOLserver technology. If it doesn't run under AOLserver, > replace it with something that does.
If someone is offering to donate freely, commercial-grade hosting on AOLserver, please contact me. > 2. Expose real world examples, and code examples. I agree. I also don't think the burden of responsibility lies solely on AOL to provide this. AOLserver is out there. The source is open and freely available. Folks outside of AOL are developing applications for AOLserver. They're free to publish their code as open source as well (i.e., OpenACS, .LRN, etc.) to serve as examples for everyone. > AOL itself has done nothing to advance database integration, and the > base nsdb module remains incomplete. Provide a list of requirements that would complete the nsdb module. > 3. Provide configuration examples. What's missing from the sample-config.tcl? Provide a list, and we can discuss whether there's value in adding it in. > I just spent a few days going through all the core code to pull out > every config parameter. Great! Publish your findings on the web so others can benefit from your hard work. > 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. This is an interesting idea. We can explore it for future AOLserver releases. > 4. Ditch the AOL moniker. EVERY person I tell about what software I use is > CONFUSED by this. Please describe their confusion. What are they confused by? What does the confusion result in? > Words have meaning and AOL doesn't really have a place in the > webserver software area. Maybe I've been drinking the Kool-Aid lately, but I'd say that AOL will continue to have a place in more and more areas. AOL made the right decision to liberate the Netscape project which became a very successful Mozilla, and perhaps Firefox should have been named Phoenix as it rose from the ashes of the browser war to win in it in the end, after everyone declared the browser wars "won" by Microsoft. While the world has declared Apache and IIS the de-facto standards for web servers, I wouldn't count AOLserver out, yet. I can easily imagine a few years down the road when the showdown turns out to be between IIS and AOL's web server. History has a tendency of repeating itself, and Microsoft may likely lose due to its product's inability to recover from inherent security issues while AOL's version doesn't have that problem to worry about. It worked for the Mozilla folks with regard to browsers ... > It just doesn't connect. AOL is a service provider, not a software > company. AOL's core values have always been about excellence and that hasn't changed, but ever since AOL's early days, what did they do? They shipped software. To millions of people. They demonstrated the raw power of direct mail marketing. They connected people in new ways, with a new medium. AOL's flagship product is software. The beauty is that they do it so well, people don't focus on that or think about it consciously. The AOLserver Project isn't at that point yet, and while it makes me sad sometimes realizing this, I know that AOL's the right company to be doing it, because they've proven they can do it, and do it well. > Ummm, the change might also send a subtle message to everyone else > here that this project is more than an AOL lapdog. Or, that AOL is abandoning the product. Changing the name could be very dangerous, and like any brand and identity management effort, needs to be planned properly, well thought out, and executed correctly. It's not something we just "decide to do" and find-replace AOLserver out of the source code. I actually think that people severely underestimate the incredible value of the AOL brand equity. I'm hoping in 2005, I can find more ways of capitalizing on it. > 5. Show us how the nsjk2 thing is supposed to work. There's installation instructions included with the source in the README.build along with a User Guide. Have you read both? What do you feel is lacking? > It appears to me, via nonreflective observation that AOL is skipping > further development of AOLserver in favor of using java technology. If you look at the CVS commit history, there's still code being committed to the AOLserver core that have nothing to do with nsjk2 or Java. Matter of fact, there hasn't been a nsjk2 or Java-related commit for a while, now. > 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, I'm not sure if I'm at liberty to discuss this yet. We'll see what can be said and/or shared once it's okay to do so. > 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. The itinerary was to make it possible to connect AOLserver to Apache Tomcat the same way Apache does with mod_jk and mod_jk2. When Apache cuts over to AJP support in mod_proxy and/or a mod_ajp, we'll likely update AOLserver to support a similar mechanism if it makes sense. It's not about favoring Java-based technologies, it's about ensuring that AOLserver is capable of supporting them adequately. > 6. Split the discussion between C level source code and applications. There's few enough AOLserver developers who deal at the C code level that having a separate mailing list for it seems unnecessary at this time. I would like to see more application development discussion take place on the mailing list, but I haven't come up with a good way of encouraging it in a meaningful way yet. Suggestions are welcome. > 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. AOLserver is not its applications. It's the core foundation that applications are built on top of. I think my statement was fair and true. > 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. See my comment above regarding AOL not having to bear the entire burden of AOLserver. If that were to be the case, what was the point of making it free and open source? > Maybe they consider this a trade secret? Certainly, the code which makes up the AOL web properties has value and will not likely be open sourced. I wouldn't call it a "trade secret" but it's definitely valuable intellectual property. > But for whatever reason, AOL has not contributed very much to an area > that will attract 99% of new users (that is application developers). I do agree. In 2005, I'd love to see the start of an AOLserver Web Development Kit (WDK), especially based around my AOLserver Standard Tag Library that I'm working on. That'd be fantastic. > Another problem is the persistence of bugs. If they are not on AOL's > list, they usually don't get addressed. There are currently 50 people with CVS commit access. Without actually looking, I'm guessing only 20% of those people are AOL employees. According to your reasoning, then there must be another 80% of people whose list these bugs aren't on, either. Or, perhaps, fixing many of these bugs isn't very important. There are several important bugs to be fixed and they're either not fixed because there's no solution yet, or people with time or capability to fix them. > 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? The discussion was carried out on the public mailing list that's archived. You're welcome to summarize the suggestions and approaches taken to try and find and track memory leaks, and publish it up on the web for everyone to benefit from. There is no "one way" to find and track memory leaks. General diagnostic and forensic practices are applicable, but there's a reason why there isn't a recipe for doing it. It takes creativity, problem solving, and keen observation. You can't "teach" that to someone by writing a guide. > How do you figure out if the leak is in core, or in a client module? You guess. You create hypotheses and tests to try and prove or disprove them. Call it trial-and-error if you like. > 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? The "connsperthread > 0" issue is definitely a bug. The irony is that the bug was completely unrelated to the memory leak that was originally reported. I recently closed a bug, that I opened, about nsopenssl_sockopen leaking memory when it was a problem with my test environment and stray code that I was testing before investigating some other memory leak that was reported to me. All this means is that I need more discipline in my testing practice. Or, that one person can't do ALL of the required project activities alone, and that it'd really help the project if folks could help out. (See my call for volunteers for a Quality Assurance Team.) > B. Application level discussion and support. There's plenty of OpenACS discussion over at the OpenACS community (forums, chat, etc.). AOLserver isn't an application that an end-user sees, so what discussion would be appropriate for this venue? > 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. Lets let the voice be a little less silent, then: Buy millions of dollars worth of hardware. Cluster the hell out of your infrastructure. Create highly specialized installations of AOLserver to solve specific problems, and couple these systems together to produce functionality whose sum is greater than its parts. Do this through developing customized modules to extend AOLserver's functionality to these specific problems. The problem is that while AOL runs one site across a farm of 30+ machines, the majority of non-AOL users of AOLserver are trying to run 30+ sites on ONE machine. AOL's advice and wisdom in the arena of architecting, developing and operating sites with AOLserver is generally not applicable since you (plural) won't be able to follow the advice. (If you can, read the previous paragraph -- that's the advice in a nutshell.) > 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. Have you read Jim Davidson's presentation of AOL's Digital City? Tcl in AOL Digital City: The Architecture of a Multithreaded High-Performance Web Site http://www.aolserver.com/docs/intro/tcl2k/html/ It's just about 5 years old now, but is still very relevant. I personally think the presentation is an excellent explanation of exactly why and how AOL uses AOLserver. > 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. For a long time now, William Webb has made some code available that implements a form of NVs: http://unresponsive.net/misc/code/ AOLserver: Broadcast - Network Variables lib_broadcast.tcl Broadcast Service It's not AOL's NV implementation, but it's *an* implementation that's already available. If having a specific feature is important to you, either implement it yourself, or wait for someone else to. If you don't want to wait, then realize we live in a free market capitalist society: you are welcome to hire someone to do the work for you. Regardless, a form of NV's is already readily available. How would you incorporate it into your application? Will your application ever get enough traffic that William's implementation will be your bottleneck? Lets discuss the matter more when you approach that point, and we'll solve the problem when it really exists. > But has anything come from my requests? Of course not. William's made his code available. If you end up using it, you should thank him. > AOLserver doesn't come with a development framework. Must it? PHP doesn't. The difference? There's a lot more freely available PHP code out there than there is AOLserver/Tcl code. Do you think the core developers behind PHP wrote and distributed all that freely available PHP code? I could be wrong, but I'd guess the answer is "no." They may have all worked on various PHP projects of their own, but the majority of the code came from the community of PHP users. What's stopping the AOLserver user community from doing the same? Lets discuss this more and come up with real answers. > It is wide open, but developers have to start from scratch, I hear many developers are starting from stock OpenACS. There's nothing saying that if you use AOLserver, you must start from scratch. > It is not obvious that if you have a medium to large project that > AOLserver is the platform you should use. What needs to be said or done in order for it to become obvious? > 8. Receptive to junior developers. Without getting personal on this matter, I want to just say that the reason why the AOLserver C code maintains an admirable level of clarity and excellence is because there's very little tolerance amongst its developers for sub-standard quality code. That attitude may mean a slower rate of change or progress, but when you're talking about software that you want to rely on to be stable, performant and secure ... sometimes that's the price you pay. There are obviously places in the code that can be improved, and over time, I hope we all work together to do that. But, I loathe the idea of making changes to the code in the name of coddling junior developers that sets us further back with respect to that goal. This is, of course, my own personal opinion and I'm sure there are those of you who disagree with me. Feel free to discuss this matter with me privately off-list. > 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. I've been known to help people troubleshoot and (usually) solve their AOLserver problems. I've never once started the dialog with "sure, but you'll need to pay me in cash." I tend to think when I ask folks to reciprocate, that they should consider responding in kind. Tom, thanks for taking the time to raise these points and I hope I've spoken to most or all of the issues you wanted addressed. If I missed anything, feel free to respond here or privately to me, as appropriate. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- 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.
