my only concen with splitting the proxy out is that
no one will actively maintain it, and keep it up to date
with the current http releases.
saying that i'm quite happy to volunteer myself to do this function,
but i'm not an ASF member, or even have commit access for that matter.
..Ian
ps .. are there any ASF members out there who work with large >10M hits/day sites?
> -----Original Message-----
> From: Chuck Murcko [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 19, 2001 11:06 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] mod_proxy in?
>
>
>
> 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
>
