After lurking on the list for quite some time I have to say that I strongly second many of Tom's comments.
PLEASE, don't take any of this personally none of it is aimed at individuals, and none is intended as anything other than constructive criticism. My thoughts mixed in below: > -----Original Message----- > [mailto:[EMAIL PROTECTED] On Behalf Of Dossy Shiobara > Sent: 05 February 2005 06:43 > > 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. I too found it odd that the AOLserver sites themselves didn't use their own technology > If someone is offering to donate freely, commercial-grade hosting on AOLserver, please contact me. Surely AOL could provide this as a way of thanking the efforts of the community developers? > > 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. There's a very serious dearth of easily usable AOLserver code out there. I suspect that many people who start to use AOLserver end up having to build for themselves the same very basic building blocks. So these basic blocks get built over and over again, making every implementation different and significantly raising the bar in terms of what is required to 'just get started' I'm an experienced Tcl programmer and had no difficulty in building a working demo 'page' (.adp or .tcl) once I'd got a working server. However it then took a whole bunch of time to implement sessions and a database driven security model, time which many people before me must have spent over and over again. Can't AOL and the AOLserver community spare some of its experience and help out by providing a recommended/reference version of some of these that would get most people started at least. > > 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. I did precisely this some time ago and published the results on this list. Guess what - sample-config.tcl came back more or less unchanged. > > 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. It is a neat idea - I'd personally take it further and put all the defaults are in the config file and suggest that the server errors without them rather than having them hardcoded hidden away in the C code. > > 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? I personally got the impression that with AOLserver I'd get something off the shelf that with a certain amount of tweaking I'd be able to build sites not unlike the AOL site, and as my sites grew I'd be easily able to scale up. It turns out that off the shelf you get a vanilla webserver. Yes it may actually be very advanced,fast,scalable etc. but only *if you know how* and that knowledge is not easily available outside of AOL > While the world has declared Apache and IIS the de-facto standards for web servers, Crazy isn't it! It is my belief that these servers have become de-facto standards, not because they excel at what they do but because they are easy to use. If they were actually any good they'd be very dangerous! :-) The number of people I speak to who think Apache is the fastest, most scalable, best webserver out there, for no apparent reason other than lots of people use it makes my mind boggle. The look of sheer bewilderment on their faces when you show the difference in performance between a multi-process and a multithreaded webserver is a sight to be seen. > 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. To me that would require more transparency on how AOL actually uses AOLserver. If AOL could release some of its architecture ideas and source code even if that code were 5 years out of date, then the community would benefit from having a truly enterprise/production ready system available off the shelf (or at least be a lot closer to this) > > 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. I too don't think splitting the list would help at this stage - you might end up with an us and them elite vs. newbies split which never helps. > > 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. I second this. AOL must have a wealth of experience developed over time on good and bad ways to use AOLserver and why they are good and bad. It must also have whole libraries of developer tools that make the lives of an AOLserver developer easier, and buckets of basic code libraries that perform fundamental things you need on a modern website. It would be great if these were available to the community even if it was just documentation of the concepts and ideas rather than actual code. > 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? If more of the above were available to the community then there'd be more chance that extensions/modifications/improvements etc made by the community would be of use to AOL themselves. At the moment with only the core server being open source, then the benefit AOL can get from the community is restricted to bugfixes and changes to the core server. > > 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. I don't think anyone here would expect the complete and exact code used to run AOL's sites to be openly published, but AOL must surely have many useful modules, tools, code libraries that are definitely *not* trade secrets up its sleeves. > > 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? Yes, but OpenACS is so, well, OpenACS....! :-) To use it at all you have to install/understand/use so much other stuff you don't want Don't get me wrong I'm not actually knocking OpenACS or the folks involved - it just wasn't what I was looking for. Having said that they do have some very useful code and I personally feel that some of the basics could usefully be split out from OpenACS into modules that can run standalone on the core AOLserver allowing both the pure AOLserver and OpenACS communities to use and develop them further. I got a certain way down the route of doing this with the OpenACS session and security modules and it works With a fairly small set of files taken straight from OpenACS - and tweaking them just a bit AOLserver can have this functionality. Whats the benefit? Well you get to use tried and tested code that has been used on community sites with many many users rather than rolling yet another home-grown version of the same stuff. > > 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. Fantastic! That's great as an introductory paragraph. Now all we need are the next 10 pages of detail about *how* you actually do all of these things. > 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. True. But at the time I was using AOLserver seriously I'd have been more than happy to make a sacrifice and have something that was more complex and less optimal for the small scale. And would have been happy in the knowledge that it was possible to scale it up to AOL size operations without too much change. > 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. It would be good if we had the choice of reading that advice and wisdom and making our own minds up about whether it applies or not. I'm sure some of it wouldn't but much of it would. > (If you can, read the previous paragraph -- that's the advice in a nutshell.) He he - I can see an O'reilly book on its way - what animal should be on the front cover? > > 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. Hear hear! This is the kind of generic extremely useful code that AOL must have lying about that is unlikely in itself to be a trade secret, but would be of huge assistance to the community developers. > 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. Hmm very interesting and very cool - last time I looked there the NV stuff was by its own admission only partially functional. > 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. Of course this is true - it is annoying though to have to spend time/money reinventing the wheel when you know that the code for that feature is available and probably an extremely robust implementation too rather than v1.0 of it that would be produced by home growing it. > 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. That's not a good argument to use. If one has a choice between some code that will handle X thousand requests/users/whatever and some that is known to handle X million requests/users/whatever, which would you prefere to use even if you don't need that capacity right now? > What's stopping the AOLserver user community from doing the same? > Lets discuss this more and come up with real answers. Because we all know that AOL already has the answers and wait in hope that some of these can be divulged. When we can't wait then we build stuff ourselves, but that doesn't lend itself to standardization. > > 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. No but you've outlined your two main choices Start completely from scratch Or Start from stock OpenACS I personally wanted something in-between and there wasn't anything I suspect I'm not alone. > > 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? The proof of the pudding is in the eating What is required is lots of tried and tested working code being used in live/production medium to large projects. Being able to dip into this code for features/tips/inspiration and take it as is, or take it and modify it for specific needs An example: - When I started using AOLserver I wanted to have user sessions so I looked around at what there is. AOLserver itself offers nothing, so I looked around for modules - there's several, some that use files for storing sessions, some that use the database, some that are in server memory. Some are pure Tcl, some are pure C modules (and not so portable), others are hybrids. So which one should I use? There's no information about how or if any of them are actually being used, by how many users, how they compare performance wise etc. etc. So I tried them out - some I couldn't get to work, some wouldn't compile, some wouldn't scale etc. so my question was left unanswered. The solution: Rip the session code out of OpenACS. It worked, it was tried and tested (though not in the 'ripped' form), it scaled to multiple servers, it was pure Tcl and so very portable, it was heavily designed for performance. However, this took a load of time to reach this point and it would have been nice if there was a module providing all of this the came with the core AOLserver. Sure it wouldn't meet everyone's needs but it would be a good starting point and if its pros and cons were documented then a developer could weigh up the benefits of using it against writing their own to meet specific requirements. -- 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.
