Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: mod_cache: store_body() bites off more than it can chew
Date: Mon, 13 Sep 2010 17:19:13 +0200
Message-ID: 
 <99EA83DCDE961346AFA9B5EC33FEC08B04A3CF9F@VF-MBX11.internal.vodafone.com>
In-Reply-To: <7425A0BE-A6FA-4609-B577-607474409FD5@sharp.fm>
Thread-Topic: mod_cache: store_body() bites off more than it can chew
Thread-Index: ActTUOx5WNtGBnuiR/G75e5HvXvyQQABbZwA
References: <68B35D56-BB55-458F-A7BB-E225AFEB8544@sharp.fm>
 <AANLkTi=huBgPvuyv3SW=mmpAv5kWhtSRBOzKBm2rsqF5@mail.gmail.com>
 <F0610651-BAD0-408D-B31C-F31CB9A72BBF@sharp.fm>
 <BFS-FE-PRD1ACkWHZqY00000159@bfs-fe-prd1.myopwv.com>
 <7FB83631-3176-468A-B10C-E84B91326DFE@sharp.fm>
 <99EA83DCDE961346AFA9B5EC33FEC08B04A3CF47@VF-MBX11.internal.vodafone.com>
 <7425A0BE-A6FA-4609-B577-607474409FD5@sharp.fm>
From: =?iso-8859-1?Q?=22Pl=FCm=2C_R=FCdiger=2C_VF-Group=22?=
 <ruediger.pluem@vodafone.com>
To: <dev@httpd.apache.org>

=20

> -----Original Message-----
> From: Graham Leggett=20
> Sent: Montag, 13. September 2010 16:35
> To: dev@httpd.apache.org
> Subject: Re: mod_cache: store_body() bites off more than it can chew
>=20
> On 13 Sep 2010, at 4:18 PM, Pl=FCm, R=FCdiger, VF-Group wrote:
>=20
> > It is not a problem for mod_disk_cache as you say, but
> > I guess he meant for 3rd party providers that could only deliver
> > the cached responses via heap buckets.
>=20
> The cache provider itself puts the bucket in the brigade, and=20
> has the =20
> power to put any bucket into the brigade it likes, including=20
> it's own =20
> custom developed buckets. The fact that brigades become heap buckets =20
> when read is a property of our bucket brigades, they aren't a =20
> restriction applied by the cache.
>=20
> For example, in the large disk cache patch, a special bucket was =20
> invented that represented a file that was not be completely present, =20
> and that blocked waiting for more data if the in-flight cache=20
> file was =20
> not yet all there. There was no need to change the API to=20
> support this =20
> scenario, the cache just dropped the special bucket into the brigade =20
> and it was done.

Yeah, but in a tricky way, which is absolutely fine and cool if you =
cannot
change the API, but the question is: Is this the way providers
should go and does the API looks like as it should?

Regards

R=FCdiger