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:


> 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.

Reply via email to