Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22108
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Sat, 4 Mar 2006 16:09:56 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <613605091.20060304160956@marcus-boerger.de>
To: Michael Wallner <mike@php.net>
Cc: internals@lists.php.net
In-Reply-To: <D3.66.37756.B4837044@pb1.pair.com>
References: <68.AB.30574.5C7E2044@pb1.pair.com> <7.0.1.0.2.20060228183807.0afb5068@zend.com> <7f3ed2c30602280858q1253487bqade24d8d92aa4cb0@mail.gmail.com> <7.0.1.0.2.20060228190317.0b522678@zend.com> <D3.66.37756.B4837044@pb1.pair.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Revisiting output control code
From: helly@php.net (Marcus Boerger)

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