Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 56225 invoked from network); 23 Mar 2007 14:13:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Mar 2007 14:13:17 -0000 Received: (qmail 95934 invoked by uid 500); 23 Mar 2007 14:13:20 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 95886 invoked by uid 500); 23 Mar 2007 14:13:20 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 95871 invoked by uid 99); 23 Mar 2007 14:13:20 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Mar 2007 07:13:20 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of jorton@redhat.com designates 66.187.237.31 as permitted sender) Received: from [66.187.237.31] (HELO mx2.redhat.com) (66.187.237.31) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Mar 2007 07:13:09 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx2.redhat.com (8.13.1/8.13.1) with ESMTP id l2NDk1Yg016410 for ; Fri, 23 Mar 2007 10:12:48 -0400 Received: from radish.cambridge.redhat.com (radish.cambridge.redhat.com [172.16.18.90]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l2ND2CRq020041 for ; Fri, 23 Mar 2007 09:02:13 -0400 Received: from radish.cambridge.redhat.com (localhost.localdomain [127.0.0.1]) by radish.cambridge.redhat.com (8.13.8/8.13.7) with ESMTP id l2ND2BDA007379 for ; Fri, 23 Mar 2007 13:02:11 GMT Received: (from jorton@localhost) by radish.cambridge.redhat.com (8.13.8/8.13.8/Submit) id l2ND26JF007377 for dev@httpd.apache.org; Fri, 23 Mar 2007 13:02:06 GMT Date: Fri, 23 Mar 2007 13:02:06 +0000 From: Joe Orton To: dev@httpd.apache.org Subject: Re: [RFC] Guide to writing output filters Message-ID: <20070323130206.GA7072@redhat.com> Mail-Followup-To: dev@httpd.apache.org References: <45FC0990.6080401@apache.org> <20070319140604.GA3237@redhat.com> <45FEFD57.4060109@apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <45FEFD57.4060109@apache.org> User-Agent: Mutt/1.4.2.1i X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Mar 19, 2007 at 10:15:03PM +0100, Ruediger Pluem wrote: [on passing empty brigades and mod_cache] > Once we detect that we have a fresh content entity in the cache, the > quick handler of mod_cache starts the filter chain by calling > > ap_pass_brigade(r->output_filters, out); > > where out is an empty brigade created by the quick handler. The brigade gets filled > with the cached content by the CACHE_OUT filter down in the chain. I think that was simply abuse of the filter interface, and fixing mod_cache was correct. If a filter was passed a non-empty brigade, it may legitimately buffer the contents of that brigade without passing it on down the chain. So to then require explicitly that an *empty* brigade *must* be passed down makes little sense IMO. ... > >>- Procesing buckets: I think with mmap enabled a file bucket will morph into > >> a mmap bucket and the remaining file bucket. I think the heap bucket will > >> only be created if mmap is turned off. But I agree that this possibly introduces > >> too much complexity to the example and distracts the reader from the important > >> point. > > > Yeah. It's an implementation detail, and the risk is that if it gets > > documented, people will rely on it somehow. > > Why can't you rely on this? Isn't that the publicly defined behaviour > of a file bucket when MMAP is enabled? Simply that there's nothing in the definition of a FILE bucket which states it will always morph into MMAP under conditions X, Y, Z. joe