Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Mon, 1 May 2006 17:18:53 -0300
From: Davi Arnaut <davi@haxent.com.br>
To: dev@httpd.apache.org
Cc: brian.akins@turner.com
Subject: Re: Possible new cache architecture
Message-Id: <20060501171853.8fd9164a.davi@haxent.com.br>
In-Reply-To: <445665B2.3010604@turner.com>
References: <4450CF63.2060305@turner.com>
	<445136CC.6030305@sharp.fm>
	<44520B45.6070507@turner.com>
	<4455203F.9000509@sharp.fm>
	<44560316.3030705@turner.com>
	<445664B1.5030905@sharp.fm>
	<445665B2.3010604@turner.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 01 May 2006 15:46:58 -0400
Brian Akins <brian.akins@turner.com> wrote:

> Graham Leggett wrote:
> 
> > That's two hits to find whether something is cached.
> 
> You must have two hits if you support vary.
> 
> > How are races prevented?
> 
> shouldn't be any.  something is in the cache or not.  if one "piece" of 
> an http "object" is not valid or in cache, the object is invalid. 
> Although other variants may be valid/in cache.
> 

More important, if we stick with the key/data concept it's possible to
implement the header/body relationship under single or multiple keys.

I think Brian want's mod_cache should be only a layer (glue) between the
underlying providers and the cache users. Each set of problems are better
dealt under their own layers. The storage layer (cache providers) are going
to only worry about storing the key/data pairs (and expiring ?) while the
"protocol" layer will deal with the underlying concepts of each protocol
(mod_http_cache).

The current design leads to bloat, just look at mem_cache and disk_cache,
both have their own duplicated quirks (serialize/unserialize, et cetera)
and need special handling of the headers and file format. Under the new
design this duplication will be gone, think that we will assemble the
HTTP-specific part and generalize the storage part.

--
Davi Arnaut