I agree. That's why the protocol handling and the caching have been separated from the monolithic C proxy a loooong time ago. 8^)
Three layers sounds interesting: 1) A protocol dispatcher/filter chain builder (replaces mod_proxy.c) 2) hookable protocol handlers for each request's filter chain 3) a separate caching function that's generic and flexible There's room for a possible "postprocessing" layer to handle GC, etc. This is stuff better done after the request is handled. Distributed proxies and caches, http acceleration, all that gets easy in this new model. Of course, all this is moot if someone's sitting out there with a functional dropin mod_proxy for 2.0 in their pocket that they want to donate to ASF. 8^) But no one's said anything about that, so here we are. The question still remains: is there enough interest in any sort of proxy to do active development? On Wednesday, February 7, 2001, at 05:13 PM, Gabriel Russell wrote: > At 01:11 PM 2/7/2001 +0000, James Sutherland wrote: > > > > There 2 jobs share some common code/functionnality but there are also > > quite > > > > different. > > Where they do share common code functionality, it's often not totally > perfect. Looking at the code I see no compelling reason to have one code > base for these two functions. Caching is the one obvious section that is > clearly sharable by the two sections. > > Forgive me for stating what may be obvious to everyone else but, Ideally, > I'd like to see three modules: > > A caching module with a generic api, such that it folks can write drop in > replacements for the standard shipped module. People could then also use > this module in any other module that could benefit from it, caching cgi, > caching internal redirect, blah blah blah. > A gateway module, just the relatively small bit of code to do proxypassing. > A proxy module, most of the current functionality, minus the cache and > proxypass code. > > Not only do I think that this makes much more sense then the current > monolithic module, but I think that it would be significantly easier to > find a maintainer for each smaller module. > > > > > Chuck Murcko Topsail Group http://www.topsail.org/
