Hi, There is lots of discussion about fixing mod_proxy and mod_proxy_balancer, to try to make it do things that the APIs are just broken for, and right now, it seems from the outside to be turning into a ball of mud.
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. Using this structure, you can implement a dynamic load balancer without having to modify the core. I think the key is to _stop_ passing around the gigantic monolithic proxy_worker structures, and go to having providers that do simple operations: get a list, sort the list, get me a connection. Thoughts? Thanks, Paul
