On Fri, Apr 12, 2002 at 04:29:27PM -0700, Justin Erenkrantz wrote: > Precisely because people haven't gotten around to it. Just > because we went GA doesn't mean that the server is perfect. > There are lots of APIs that we could optimize or enhance. > I am merely pointing out that I think this is an API that we > would be better off living without. In retrospect, I should > have removed these functions while I was cleaning up the input > filtering. This would have brought this issue up sooner, but > now that we are GA, this API can't be changed. ... > I believe the breakage that Aaron is seeing is because that > API is fundamentally broken. If you wish to cling to the 1.3 > API, fine with me. I think we will end up hurting ourselves > by trying to stick with the old APIs forever. Our entire > server is built around buckets and brigades - trying to isolate > the modules from them seems to me like a lost cause. > > I now don't care what you end up doing, but Aaron's patch is not > the right solution. If you wish to come up with a solution that > maintains the old API, go ahead. My only caveat will be that > you can not break the filters in the process. I believe it must > be permissible for a module to rely on the filters to enforce > HTTP compliance not a 1.3-compatible API that doesn't understand > buckets and brigades. -- justin
If you have a better way to deal with this, I *strongly urge* you to make a proposal. If the API you propose is better than what we have now I see no reason why we wouldn't make the change. Just because we've gone GA doesn't mean we can't try to fix what's broken, even if it means some work for our module authors. Of course, the amount of work we impart on our module authors must be justified. In the mean time, assuming for now that we will stick with these old APIs for the forseable future, do you see any technical reason why my patch shouldn't be committed? (I did some pretty good testing of it, but I can't test everything.) -aaron
