From minfrin@sharp.fm Thu Nov 16 14:42:39 2000 Return-Path: Mailing-List: contact modproxy-dev-help@apache.org; run by ezmlm Delivered-To: mailing list modproxy-dev@apache.org Received: (qmail 51549 invoked from network); 16 Nov 2000 14:42:39 -0000 Received: from infobase.ericsson.nl (193.78.100.33) by locus.apache.org with SMTP; 16 Nov 2000 14:42:39 -0000 Received: (qmail 28267 invoked by uid 0); 16 Nov 2000 14:42:08 -0000 Received: from dsnstar.dsn.ericsson.se ([164.48.68.130]) (envelope-sender ) by infobase.ericsson.se (qmail-ldap-1.03) with SMTP for ; 16 Nov 2000 14:42:08 -0000 Received: (qmail 25743 invoked by uid 0); 16 Nov 2000 14:42:03 -0000 Received: from unknown (HELO sharp.fm) (minfrin@164.48.154.118) by dsnstar.dsn.ericsson.se with SMTP; 16 Nov 2000 14:42:03 -0000 Sender: minfrin Message-ID: <3A13F468.2F3D00BE@sharp.fm> Date: Thu, 16 Nov 2000 15:51:20 +0100 From: Graham Leggett X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.17 ppc) X-Accept-Language: en MIME-Version: 1.0 To: modproxy-dev@apache.org Subject: Re: mod_cache and the proxy. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N rbb@covalent.net wrote: > I have really spent a lot of time in the proxy today, and a lot of my > opinions have changed. Here is where we are right now IMHO. > > 1) The cache that is in the proxy. This is messing up the code and > should be removed. The cache is done for Apache 1.3, and that is just > wrong for 2.0. I plan to spend some time tomorrow afternoon to rip the > cache out of the code. Effectively mod_proxy should be 100% straight through - with the request from Apache being forwarded as-is to the backend, and any reply being returned again as is into the filter chain (so that uncompressed backend webservers can pass through compression filters, etc etc). > 2) BUFF. This is wrong. We can remove a lot of duplicated code if we > can use filters for the back-end communication. I think I see how to do > this VERY cleanly, but I need to actually write the code. Expect this to > be done tomorrow sometime. Ok. > 3) mod_cache.c. This needs to be done. Since there are arguments > against putting it into CVS before it is ready, I am considering setting > up a CVS repository on my home machine to allow people to collaborate on > this cleanly. I would ask people to give me a day to get this all > setup. If somebody already has a CVS server setup for public use, and > they want to host this module until it gets stable, please speak up. I've been meaning to put some more detailed effort into the design docs that I posted a few weeks ago, but I've been snowed under with a burning project and it's been taking up too much of my time. How close to the design is the mod_cache you have created? Regards, Graham -- ----------------------------------------- minfrin@sharp.fm "There's a moon over Bourbon Street tonight..."