Please review my attempt [0] to reimplement the output control code and make
your opinion, support or objections public. A patch [1] to try, the API [2]
and the actual code [3] are online for review. There's alse a README [4]
explaining the what-why-how.
Remaining issues:
-
Getting rid of ext/zlib related code in SAPI.c (and elsewhere?) as this
can be handled then from within the output handler. Make the gz handlers
benefit from the new implementation. -
ob_implicit_flush(): In the very original implementation (and in the
documentation) ob_implicit_flush disabled output buffering, but it didn't in
the recent code; restore that functionality? -
Look into solving the bit about xmlrpc errors in main.c.
References:
[0] http://dev.iworks.at/PATCHES/output/
[1] http://dev.iworks.at/PATCHES/output/ob.patch.txt.gz
[2] http://dev.iworks.at/PATCHES/output/php_output.h.txt
[3] http://dev.iworks.at/PATCHES/output/output.c.txt
[4] http://dev.iworks.at/PATCHES/output/README.NEW-OUTPUT-API
Thanks,
Michael - <mike(@)php.net> http://dev.iworks.at/ext-http/http-functions.html.gz
I wrote:
References:
[0] http://dev.iworks.at/PATCHES/output/
[1] http://dev.iworks.at/PATCHES/output/ob.patch.txt.gz
[2] http://dev.iworks.at/PATCHES/output/php_output.h.txt
[3] http://dev.iworks.at/PATCHES/output/output.c.txt
[4] http://dev.iworks.at/PATCHES/output/README.NEW-OUTPUT-API
Should I interpret the sustained silence as no interest in it?
Regards,
Michael - <mike(@)php.net> http://dev.iworks.at/ext-http/http-functions.html.gz
Hello Michael,
Friday, March 17, 2006, 4:09:12 PM, you wrote:
I wrote:
References:
[0] http://dev.iworks.at/PATCHES/output/
[1] http://dev.iworks.at/PATCHES/output/ob.patch.txt.gz
[2] http://dev.iworks.at/PATCHES/output/php_output.h.txt
[3] http://dev.iworks.at/PATCHES/output/output.c.txt
[4] http://dev.iworks.at/PATCHES/output/README.NEW-OUTPUT-API
Should I interpret the sustained silence as no interest in it?
I'd say the only thing that doesn't look ten times better than what
we have right now is that you have exported function prefixed with
underscore "PHPAPI int _php_output" and static ones without. Imo
it should be the other way round. The open question i have however
is how do you deal with unicode. I saw some estr*() calls where
i would have expected a few unicode checks. So there is no unicode
support right now. So i suggest you add that too.
A think i am a bit curious yout is why some function have both
*() and *_all() versions. Why didn't you choose to pass an int in?
Last but not least i wonder why i am seeing use of the strange
TSRMLS_FETCH_FROM_CTX() instead of passing TSRM keys using TSRMLS_*
macros.
Best regards,
Marcus
Marcus Boerger wrote:
I'd say the only thing that doesn't look ten times better than what we have right now is that you have exported
function prefixed with underscore "PHPAPI int _php_output" and static ones without. Imo it should be the other way
round.
This is because the TSRM macros don't have underscores, so one
uses php_output_flush() instead of _php_output_flush(TSRMLS_C)
of course. So the public API except that used in main.c or
in SAPIs is TSRM macro free (like in the streams layer or
pecl/http and possibly else where).
The open question i have however is how do you deal with unicode. I saw some estr*() calls where i would have
expected a few unicode checks. So there is no unicode support right now. So i suggest you add that too.
I don't yet see why output control should know about or handle
unicode differently, it basically just shovels binary data around.
I didn't dive into the unicode stuff yet, so I might be quite off...
A think i am a bit curious yout is why some function have both *() and *_all() versions. Why didn't you choose to
pass an int in?
Because the *_all() functions don't honor if the handler is cleanable
and/or removable, those are ultimate functions like for shutting down
the output control layer. I think it's better to have separate functions
to emphasize this difference.
Last but not least i wonder why i am seeing use of the strange TSRMLS_FETCH_FROM_CTX() instead of passing TSRM keys
using TSRMLS_* macros.
This is only used in zend_stack_apply callbacks which don't support
TSRM by signature.
Thanks,
Michael - <mike(@)php.net> http://dev.iworks.at/ext-http/http-functions.html.gz