On Jan 11, 2005, at 11:00 AM, Jim Jagielski wrote:
Theo Schlossnagle wrote:
Having mod_backhand use mod_proxy isn't very difficult. We implemented
that for a client. I don't understand the comment about the web server
doing stuff. mod_proxy sits inside apache and adheres to the same
limitations do to it architectural position as mod_backhand.

Just that just because you *can* implement something in the web server, doesn't mean you *should* or *must*. A web server is part of one's web infrastructure, not its entirety.

I absolutely agree. I misunderstood you. It sounded like you were arguing against mod_backhand and for mod_proxy on the basis that the web server isn't the right place to be doing it... As the both live in the web server proper, it seemed an awkward position.


If y'all want to build a good load balancer, use APR and stay our of the Apache server proper completely. It would afford you the opportunity to scale better as much of the plumbing within Apache that guides it architectural design can be shed.

Graham and I talked about how to make mod_proxy "backhand capable" for some time. Neither of us had time on our hands to look at it. mod_backhand isn't a proxy framework, it is a decision making framework that allows complex, adaptable decision making functions to be applied and a collaborative manner using the concept of peer-to-peer systems. The fact that the current version of mod_backhand has its own internal proxying code instead of using mod_proxy via the EAPI is simple a testament to its roots (outside of Apache).

I am not at all against making mod_proxy a good load balancer. It would, however, be a shame to lose the innovations (if in concepts only) that has already occurred in a similar project.

// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
// Ecelerity: fastest MTA on Earth



Reply via email to