Re: Re: output handlers

Zeev Suraski wrote:

At 17:00 06/08/2002, Yasuo Ohgaki wrote:

Zeev Suraski wrote:

I haven't noticed this discussion before, but I'm very much against

Don't worry you haven't miss much.

removing or deprecating output_handler. If you want to write a portable app, you should indeed register output handlers in your app; But generally speaking, output handlers are functions which are very likely to be implemented on a site-wide basis, and not necessarily a script- or app-wide basis. For such purposes, php.ini is the right place.

Ok. You are asking for trouble and some people criticize "PHP is endlessly configurable by php.ini" :(

I'm very much against configuration options that affect the way the language behaves; But supplying server-wide settings that allow you to deploy your site in a certain way are a good thing in my opinion. They should also be transparent to well-written applications. Why would an I18N app not work with output_handler?

It's inconvenient/convenient like magic_qoute_gpc. If output handler is commonly used, programmers have to check if incompatible handler is registered in php.ini or not. Otherwise it may be end up with meaningless output/error. (For example, iconv handler should not be used with mbstring handler. The same applies to input handler...) Marcus and my idea is detecting wrong usage of output handlers. However, it's not only bug prone, but also the resolution introduces new issues as described. The best approch is not using the output_handler directive in php.ini. Any objection for discouraging output_handler usage? -- Yasuo Ohgaki