On Wed, 7 Feb 2001, Gabriel Russell wrote: > At 01:11 PM 2/7/2001 +0000, James Sutherland wrote:
Eh? The next quote was not mine! > > > > 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. Not even that, perhaps - the nature of caching needed is very different. > 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. I suspect a better solution would be a very simple, standalone daemon acting as an "http router" - just accept connections and proxy the data to/from a backend server (or a cache, perhaps) based on the request's nature (source IP, URL requested, backend load levels, whatever). I'm actually writing something which could do this anyway (in the very early stages, though!). Plan: Various policies available to decide how to handle each request: * Backend server load * Source IP - redirect to a nearer mirror, perhaps * URL requested - separate static and CGI requests * Cache - if we've got a suitable cached item, send that Thoughts?? James.
