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.
