On Thursday 09 August 2007 08:46, Jim Davidson wrote: > Otherwise, technically there are a few things that could be fixed to > solve some pain points: > > -- Close the gap between AOLserver's init framework and Tcl's package > framework so tcllib, ActiveState Tcl, etc. can be used easily (needs > those things to be verified, compiled, and available thread-safe)
More integration with the Tcl community is important. Both communities have added to the other. What are the issues? What would be the result of closing the gap? > -- Figure out some AOLserver-as-an-Apache extension thing -- perhaps > a more convenient proxy (seems possible) or a direct Apache module > (possible but perhaps too incompatible and goofy to be useful). I have never been able to put my finger on what the issue is here. AOLserver isn't Apache. Sendmail isn't Qmail either. Both compete over a single privileged port. That is the real issue. Some company only has one IP address and needs to make a choice. Then just run AOLserver on an internal IP and proxy through to it. That is the module. Call AOLserver an application server and Apache a firewall. Nobody is complaining that Oracle doesn't run inside AOLserver or Apache, what difference does it make if your application server is a separate process, maybe on a separate machine. Really it is a benefit, a security feature. > -- Close some API's gaps, e.g., Url2File (aka mod_rewrite) only > available in C and goofy to use. This was once an add on module for AOlserver, now it is part of the Tcl API: ns_internalredirect. > It seems if we got those things done we could then consider other > cool ideas, e.g., new language support (js, php) which shares the adp > output buffer so you could mix-match, better integration with > memcached, etc. The largest risk of AOLserver falling behind and being dropped is if the codebase doesn't keep up with any changes to Tcl. Other efforts, like adding new languages (except maybe the js spidermonkey) seem more likely to fracture the synergy with the Tcl community. Another risk is the internal, core development. If AOL has not take up 4.5, then this is an indication that performance is good enough. John Buckman's benchmarking seems to indicate that performance is great. Although it is easy to just let whoever has time to commit changes to the core code, this is an issue which really needs to be addressed. Bug fixes are an obvious exception, but not every feature must be included in the core code. The rewrite command above was originally provided as a module. So I think we need a list or set of guidelines on what core changes are acceptable. Obviously internal API changes, data structures, etc. will require core changes, but just adding in a few lines here or there to support a single feature should be discussed quite a bit. Why can't a module work? Maybe the core change should be that which allows the feature to be added as a module. For large scale API or data structure changes, we need an isolation of this development code from the current production code. We can no longer rely on the fact that AOL will have the manpower or will to finish up anything that gets started. Using the sourceforge cvs as a private code repository for any and all development needs to be stopped. Developers really need to feel responsible for not breaking other user's code. This is not cool, and will very quickly drive users away. Who wants to invest their time if the next release will not work for them? If this is not an important issue for the developer, maybe they can learn to make their own private codebase. It is just not a valid argument that since the developer put in the time, they have any right to force their code changes upon the community. > Is it time to bucket these ideas and vote on what, if anything, to do? I think there needs to be a community process which respects the current user base and the code that runs on the current core. This is an investment. All the users here have overcome all of the things we wish others to overcome to join our community. However, if the first thing we offer our new guests is our willingness to trash our existing users' investment, who will feel safe that their decision is a good one? If our diminishing resources are divided up on entertaining our new guests who speak in another language, who is going to benefit from that? The new users ask a php question. Who is here to respond? It is not just a question of programming time. This is community time, community resources. If my hour of time requires the community to spend 8 hours, have I helped anyone? 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.
