--On Sunday, August 1, 2004 10:54 AM +0100 Nick Kew <[EMAIL PROTECTED]> wrote:
(btw, if you think AP_FTYPE_RESOURCE should be AP_FTYPE_CONTENT_SET, that's another weakness of the architecture. If we need to transcode *before* a content filter, then we can't use CONTENT_SET. Solution: this needs to be configurable).
Best configurable via C code not our one-off-XML configuration syntax. ;-)
(How about moving our config syntax to Python? Whitespace matters! j/k)
The point is that content-length *is* set by many handlers, and has to be unset by filters. The second point is that there *are* a bunch of bugs arising from that (e.g. mod_deflate in 2.0.x vs recent fixes in 2.1-HEAD). The KISS principle tells us that simplifying the task of filtering content will reduce the bug count.
*nod*
Instead of requiring every filter to worry about that, we let filters simply declare their behaviour.
My point is they won't know what their behavior is until after they start executing.
going to provide any real benefits. Nothing can make use of that knowledge anyway because they have to account for all cases! So, any benefit for corner-case optimization is lost by the increase in complexity just added.
No, the whole point is to *reduce* complexity!
I wish, but I'm not seeing how it'll reduce the complexity. I think the complexity in managing the state transitions would overwhelm it. -- justin
