Re: Re: output handlers

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" :( If developers are going to write script that is I18N & portable script, output_handler directive became trouble maker. Developer may assume users won't output_handler, though. Anyway, we can discourage and warn people who are willing to use output_handler. I'm not insisting removing it. (Well, I'm one of the user, too) IMO, adding code that detects output buffer usage problems does not worth the effort. If we must detect, we should write generic output buffer dependency/problem checker. -- Yasuo Ohgaki

At 12:13 06/08/2002, Yasuo Ohgaki wrote:

James Cox wrote:

er, why did you post this to php-cvs and not php-dev?

I've missed this post unless you ask this. Generally speaking, less php.ini settings is good for application writers who write portable scripts. In order to deal with the issue, output_handler ini directive is better to be removed. (or strongly discourage using it) For example, if there is no output_handler directive, we don't have to check MIME type, if we may convert encoding or not. (The check code is added recently...) If we remove the directive, we can forget about buffer consistency except for zlib.output_compression and ob_gzhandler. (we are better to discourage use of ob_gzhandler, also) Without output_handler, users are responsibe to make buffers consistent. There is a function to check buffer status/list for this purpose. We are unable to check user defined buffer consistency, anyway. How about remove the output_handler directive, instead? It's much simpler solution and encourage people to write a portable scripts. -- Yasuo Ohgaki

-----Original Message----- From: Marcus Boerger [mailto:marcus.boerger@t-online.de] Sent: Tuesday, August 06, 2002 4:19 AM To: php-cvs@lists.php.net Subject: [PHP-CVS] output handlers The problem: Using both internal zlib output compression (in preference to ob_gzhandler) and mb_output_handler. The solution and some side effects: 1) Use ini settings (incl. new zlib.output_handler) as followed:

     'output_handler =
     'zlib.output_compression = On
     'zlib.output_handler = mb_output_handler

The new ini setting does the same as output_handler but only if zlib.output_compression is active and after it is being activated. 2) ob_gzhandler, mb_output_handler, ob_iconv_handler cannot be called twice. 3) ob_gzhandler cannot be combined with internal zlib compression and mb_iconv_handler cannot be combined with mb_output_handler. 4) You can supply more than one handler with ob_start() by either use a comma separated list (NO TRIM YET) or an array. 5) You can supply more than one handler from ini settings output_handler and zlib.output_handler by a comma separated list (NO TRIM YET). What is left: 1) Someone to test url rewriting / session handling (Haven't had time yet). 2) Check userland handlers.

-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php