Hello Michael, i never liked the output buffering code much becuase i find it too complex and too much stuff there is interacting in a way one cannot understand easily. If there is a simple solution at hand that solves some problem and that thing disables selective features by just disallowing invocation of certain control function i'd never be against. If it fixed a problem at hand i'd be all for it of course. Anyway that would only increase the complexity. So yes a redisign wouldn't hurt. And if that means we could get rid of strange side effects of stuff that is imo abusing the output buffering by using a temporary output buffer i'd appreciate it. However as said on irc i am not sure it's worth the effort and cannot make out how much new problems we'd head to. That you even provide a nice looking patch here shows that you are confident with the idea and agree to do the work.
best regards marcus Thursday, March 2, 2006, 7:24:09 PM, you wrote: > Zeev Suraski wrote: >> I misread the post, I thought we were talking about ob_end_clean(). >> Yes, ob_clean() may cause this problem to happen, but again, the right >> approach would be having an 'applicative' output buffer on top of the >> gzip output buffer. We can look into letting output handlers denote >> that ob_clean() is not allowed on them. > This would be in deed an option. > If you still consider a rather fundamental enhancement of the output control > code, please take a look at my initial try. It already /seems to work/ but > probably misses a few things. I must admit though, that I did not fully > understand the current implementation. > Considered issues: > Support of contexts for internal output handlers that had to maintain > it in a global variable, which caused those handlers being only usable > once; while often natural, like for the gz handler, still a limitation. > Conflict handlers, so that one doesn't need to incorporate that > code directly in output.c, but register them from within an extension etc. > Distinct ops, like FLUSH and CLEAN to signal the handler what's > going on; there should also be a possibility to change the abilities of > a handler in runtime, which is not implemented yet, eg. the gz handler > could remove the CLEANABLE and REMOVABLE flags when the first output > did pass through it. > Unfortunately I don't know which version of re2c Ilia used to generate > the url scanner, so a big part of the diff is pretty useless; note that > the patch is against current 5_1 CVS. > http://dev.iworks.at/PATCHES/ob.patch.txt.gz > http://dev.iworks.at/PATCHES/output.c.txt > http://dev.iworks.at/PATCHES/php_output.h.txt > Thanks a lot, > -- > Michael - <mike(@)php.net> > http://dev.iworks.at/ext-http/http-functions.html.gz Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
