Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 15147 invoked from network); 2 Sep 2003 02:39:38 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 2 Sep 2003 02:39:38 -0000 Received: (qmail 27582 invoked by uid 500); 2 Sep 2003 02:39:05 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 27541 invoked by uid 500); 2 Sep 2003 02:39:04 -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: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 27495 invoked from network); 2 Sep 2003 02:39:03 -0000 Received: from unknown (HELO scotch.ics.uci.edu) (128.195.24.168) by daedalus.apache.org with SMTP; 2 Sep 2003 02:39:03 -0000 Received: from [10.0.1.61] (pv106211.reshsg.uci.edu [128.195.106.211]) (authenticated bits=0) by scotch.ics.uci.edu (8.12.6/8.12.6) with ESMTP id h822ZFw8009062 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 1 Sep 2003 19:35:15 -0700 (PDT) Date: Mon, 01 Sep 2003 19:35:26 -0700 From: Justin Erenkrantz To: dev@httpd.apache.org Subject: Re: [PROPOSAL] Remove ap_*_client_block in 2.1 series Message-ID: <2147483647.1062444925@[10.0.1.61]> In-Reply-To: <20030831231901.D1650-100000@fenris.webthing.com> References: <20030831231901.D1650-100000@fenris.webthing.com> X-Mailer: Mulberry/3.1.0b6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.60-cvs X-Spam-Checker-Version: SpamAssassin 2.60-cvs (1.186-2003-05-09-exp) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N --On Sunday, August 31, 2003 11:27 PM +0100 Nick Kew wrote: > AIUI 2.1 is supposed to be a minimal change from 2.0. This proposal > will break (an unknown number of) 2.0 modules. Last time I looked, No one ever said 2.2 is supposed to be a minimal change. =) The point of making a number of 2.1 releases before 2.2 is to allow time for module writers to adjust to the new API in whatever way they need to. IMHO, this was our mistake last time - we released a 2.0 GA release before we had the API 'finalized,' and didn't allow gestation for module writers to adapt to the new 2.0 API. Once we do a 2.1 RC, the API will be fixed, and there will be a few months (?) for module writers to get ready. (Compare with Linux 2.4 and 2.6 kernel drivers.) > it was the only *documented* API for reading input data. IMO better > to mark it as deprecated, but leave it in until something is > *expected* to break third-party modules (like 1.3->2.0 did). ap_get_brigade() is the recommended approach and has been available for the entire 2.0 series and is fully documented. We haven't been explicit that ap_*_client_block should be removed, but I've posted on this list several times how to take an old module using the ap_*_client_block API and switch it to equivalent ap_get_brigade logic. Regardless, I would expect in a 2.1 RC or 2.2 release, we would have an 'upgrading' guide to explain how to switch code using ap_*_client_block to ap_get_brigade. Note, in this particular case, if you switch your module to using ap_get_brigade(), you'll be backwards source-compatible with 2.0 and 2.1/2.2. And, 2.0 will have ap_*_client_block forever. ;-) > What about that other inconsistency: the difference between > ap_rputs/family in Handlers and ap_fputs/etc in Filters? The subtle > difference to the arguments to these is - erm - annoying! ISTR there was a vote before my time on this issue. Anyone? -- justin