httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: [PROPOSAL] Remove ap_*_client_block in 2.1 series
Date Tue, 02 Sep 2003 02:35:26 GMT
--On Sunday, August 31, 2003 11:27 PM +0100 Nick Kew <nick@webthing.com> 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

Mime
View raw message