On Thursday, April 19, 2001, at 03:17 AM, Greg Stein wrote:
> +1 on option c/d.
>
> time T: httpd releases httpd-2.0.x (no proxy)
> time T': proxy releases the module
> proxy team releases httpd+proxy bundle
>
> Basically, like (d) where the team can be self-directed, but bundles are
> still released. An httpd release comes out, the proxy guys sync up,
> test,
> then release a proxy module and a proxy+httpd bundle.
Now I get it. I wasn't getting that last step (bundled release, but we
bundle it). I think we'd (developers on mod_proxy) prefer to run closer
to c) just to minimize the code skew within proxy<->httpd release
development cycles. That's really been a headache for us bugfixing. It's
the reason part of each of us (proxy people) just wants the code to be
back in the core. It also makes enhancements available quicker.
This may just also solve the converse complaint: that Big Sites want
this stuff bundled so they can Just Use It. Ian? Iain?
> Even though I'm not seriously clueful on the proxy development, I'm with
> Chuck in thinking there is a lot of cool/interesting/bunches o' work
> that
> could be done on proxy. Mostly in the realm of caching, but also in
> increasing conformance and functionality. I also see different packages:
> reverse, non-caching proxy (just a fancy gateway for mapping multiple
> servers into one namespace); add caching; forward proxy; add caching;
> etc.
>
Cool. How about a connection pooling filter, generic? That's on my list.
Chuck
