> 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.
This already exists. It needs to be bulked up, and made to cache correctly, but I suggest looking at mod_cache in modules/experimental. What is there is a proof of concept, but it shouldn't be hard to expand upon. > 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. A proxy and a reverse proxy are incredibly similar things. The biggest difference is what is the machine that the proxy is sending the data to. In one case, that is found in the request itself, in the other it is in configuration data. These two functions really should be a single module where a good portion of the code is shared. Take a look at the definition of a gateway in RFC2616, it is basically saying, as I read it, that this is a proxy that looks to the outside world like an origin server. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
