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