httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [VOTE] mod_proxy in?
Date Thu, 19 Apr 2001 07:17:08 GMT
+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.

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.

Cheers,
-g

On Thu, Apr 19, 2001 at 01:58:11AM -0400, Chuck Murcko wrote:
> 
> On Wednesday, April 18, 2001, at 11:21 PM, Chuck Murcko wrote:
> 
> > Does anyone want to rescind or change a vote?
> >
> 
> Given the points of view perhaps it's better to ask which of these 
> alternatives seems closest to consensus:
> 
> a) Treating mod_proxy maintenance as tied to httpd, mod_proxy 
> development as running on httpd major (m.n) release cycle, mod_proxy 
> code as part of httpd-2.0 cvs repository and is released with httpd 
> distribution.
> 
> b) Treating mod_proxy maintenance as tied to httpd, mod_proxy 
> development as running on httpd major (m.n) release cycle, mod_proxy 
> code has its own cvs module (hey, we can start module-2.1 now, right), 
> and is released with httpd distribution.
> 
> c) Treating mod_proxy maintenance as NOT tied to httpd, mod_proxy 
> development as running on its own release cycle, mod_proxy code has its 
> own cvs module (hey, we can start module-2.1 now, right), and is 
> released with httpd distribution. Note that this may require some 
> reintegration at each httpd release (and more work than b).
> 
> d) Treating mod_proxy as a separate project like mod_perl, on its own 
> maintenance and development cycle, own repository, own release dates, 
> and is not released with httpd, but runs under apache.org.
> 
> e) not even remotely any of the above
> 
> Note that, unlike Graham, I presume that there is future 
> development/redesign to be done on mod_proxy.
> 
> It'd sure be nice to not have to hit a moving target whilst riding in a 
> rollercoaster, though. 8^)
> 
> Chuck Murcko
> Topsail Group
> http://www.topsail.org/

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message