[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    Re: [PROPOSAL] Remove ap_*_client_block in 2.1 series
From:       Nick Kew <nick () webthing ! com>
Date:       2003-08-31 22:27:11
[Download RAW message or body]

On Sun, 31 Aug 2003, Justin Erenkrantz wrote:

> I'd like to axe ap_{setup|should|get}_block in future releases (i.e. 2.1+).
>
> The problems with ap_*_client_block are:
>
> - Errors can not be returned to the client successfully (only -1 allowed)
> - Inconsistencies because the filtering API returns EOSes inlined with data
>   (ap_get_client_block requires a separate call for EOS return)
> - Duplicate processing of headers to support ap_should_client_block.
>   (We'll be able to shrink request_rec a bit.)
>
> We've supported it in 2.0 alongside the new ap_get_brigade API.  I've got a
> fix for Stas's showstopper in the tree for 2.1 that I proposed for 2.0.  But,
> I'd like to yank it for 2.1 because I don't believe we should be supporting
> this API moving forward.

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,
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).

OTOH I agree with your points about its weaknesses.

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!

-- 
Nick Kew

[prev in list] [next in list] [prev in thread] [next in thread]