On Wed, May 6, 2009 at 11:46 AM, Jim Jagielski <j...@jagunet.com> wrote: > > On May 6, 2009, at 2:26 PM, Paul Querna wrote: > >> Hi, >> >> I think the right way to frame the discussion is, how should the API >> optimally be structured -- then change the existing one to be closer >> to it, rather than the barrage of incremental changes that seem to be >> creating lots of cruft, and ending up with something that still >> doesn't do what we want. >> >> I think mod_proxy's decisions on what to proxy to, and where, should >> be designed as a series of hooks/providers, specifically: >> >> 1) Provider for a list of backends -- This provider does nothing with >> balancing, just provides a list of Backend Definition (preferably just >> keep it apr_sockaddr_t?) that a Connection is able to use. -- Backend >> status via multicast or other methods go here. >> 2) Provider that _sorts_ the list of backends. Input is a list, >> output is a new ordered list. -- Sticky sesions go here, along with >> any load based balancing. >> 3) Provider that given a Backend Definition, returns a connection. >> (pools connections, or open new one, whatever) -- Some of the >> proxy_util and massive worker objects go here. >> > > I recall at one of the hackthons this being proposed and I > think it's the right one... It's a clear separation of functions > similar to the changes we've done in authn/authz, moving from > monolithic to more structured and defined concerns. > > The incremental changes are just so we can keep 2.2's proxy somewhat > useful and flexible enough to survive until the next revamp.
Stop worrying about 2.2, and just focus on doing it right -- then ship 2.4 in 3-4 months imo, trunk really isn't that far off from being a decent 2.4, it just needs some cleanup in a few areas. It has already been 3.5 years since 2.2.0 came out, its time to move on in my opinion.
