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
