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
