On Thursday 02 August 2007 08:17, Michael Andrews wrote: > I think these are all valid concerns and comments. But let's not > confuse the 2 very separate issues here. :-) > > The goal of yesterday's pools.tcl was to set the "default" pool's > params from the config. This was done so it would be backward > compatible. This is not in the HEAD. This is a good patch. This is > done. >
I explained why this is not true. The new code in pools.c is not using the virtual server information to separate threadpools. If you cannot acknowledge the difference, or if you are not aware of the difference, this would be a good place to start. Your work and mine from yesterday was pretty much a complete waste of time due to the bad code in pools.c. > The OTHER issue is the ns_pools command itself. This command is a > Tcl command to create and register pools. It is NEW in 4.5. If there > are bugs/issues with this command - they should be addressed for the > next release or patch. > This is not separate! AOLserver 4.0.10 combined configuration with registration, just because the AOL team replaced working code with broken and separate code doesn't make this a separate issue. The only thing new in 4.5 is the lack of recognition for virtual servers, how threadpools are defined, stored and retrieved is the same. > I am very very very happy to see so much enthusiasm over AOLServer. > The contributions made here have been valuable. Without the > community AOLserver would have been dead 2 years ago. So now we just > need to get a few things in place to facilitate continued > development. 1) We should use the SourceForge site to enter bugs and > feature requests so they are documented. Tom - it would be great if > you could document your findings concerning ns_pools there. 2) > Project owner(s) to determine roadmaps, releases, features, and > schedules. 3) Volunteers to do work, commit code, and lead > discussions. I think we are on the right track for most of this, and > I am sure Dossy has thoughts on it all. :-) I'll continue to document problems here so everyone knows about them, not everyone subscribes to the sucky sourceforge bug tracker. About the only thing I can ever figure out from those emails is that someone made a change, issue emails are impossible to quickly understand. Second, you really need to stop asking for volunteers to do work, we are all here volunteering to discuss what should be done, which is what really needs to be done first. The first thing that should be discussed is some frank statements of the situation inside AOL: * who is working on AOLserver at AOL, * how much time is assigned for this work, * any unstated policies or goals which would cause AOL developers to ignore the community, * why AOL thinks this is acceptable behavior for developers, * if AOL developers should pledge to submit to community goals and standards for all public code. Most long time members of the AOLserver community are well aware of the history of AOL employees ignoring us, but this is usually backed up with superior code. That has been the one saving grace, now that is gone and nobody should be excusing AOL's BS any longer (I'm guilty of it up through yesterday, sorry). What is needed is some indication that the AOL developers understand the problem (they are 100% responsible for creating), otherwise we just have ass covering, there is simply no nicer way of putting it. 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.
