# Output buffering patch - Thread: https://externals.io/message/47557 - Original archive: https://news-web.php.net/php.internals/47557 - Started by Lukas Kahwe Smith on 2010-03-24T10:54:53+00:00 - Messages: 13 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #47557 — Lukas Kahwe Smith — 2010-03-24T10:54:53+00:00 URL: https://externals.io/message/47557#47557 Hey, Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #47571 — Jani Taskinen — 2010-03-24T17:17:28+00:00 URL: https://externals.io/message/47557#47571 · In reply to: #47557 24.3.2010 12:54, Lukas Kahwe Smith wrote: > Hey, > > Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation. ROFLMAO. You can stick your RFCs where sun does not shine. I will not contribute anything as long as you're acting like some project manager. --Jani --- ## #47577 — Ferenc Kovacs — 2010-03-24T18:29:26+00:00 URL: https://externals.io/message/47557#47577 · In reply to: #47571 > 24.3.2010 12:54, Lukas Kahwe Smith wrote: > > […] > about the bugs fixed, known BC breaks and (undocumented) edge case changes. > This would be helpful for anyone wanting to review their code and testing as > well as documentation. > > ROFLMAO. You can stick your RFCs where sun does not shine. I will not > contribute > anything as long as you're acting like some project manager. > > --Jani > > > -- > > > > And you did it again... Tyrael --- ## #47579 — Hannes Magnusson — 2010-03-24T20:10:43+00:00 URL: https://externals.io/message/47557#47579 · In reply to: #47557 > Hey, > > Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation. > I really do not see why this even needs a discussion. Its been in trunk for years already. People have had plenty of time to give feedback. Is there really anyone who doesn't want this committed? For what reason? -Hannes --- ## #47580 — Lukas Kahwe Smith — 2010-03-24T20:12:49+00:00 URL: https://externals.io/message/47557#47580 · In reply to: #47579 > > > […] > > I really do not see why this even needs a discussion. Its been in > trunk for years already. People have had plenty of time to give > feedback. > > Is there really anyone who doesn't want this committed? For what reason? This isnt about getting a reason not to commit this. As you can see in the above quoted mail from me, I was asking for this RFC for various other reasons. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #47581 — Hannes Magnusson — 2010-03-24T20:26:17+00:00 URL: https://externals.io/message/47557#47581 · In reply to: #47580 > > > > > […] > > > This isnt about getting a reason not to commit this. As you can see in the above quoted mail from me, I was asking for this RFC for various other reasons. > Search the archives. Do your homework. 3 years and 9 months ago the patch was posted to internals for review. It included README files, TODO list, tests, tests, tests and explanations. Few weeks later it got committed. The commit got reviewed by various parties and some enhancements were made. Every single procedure was followed to the letter. People were happy. You cannot seriously be expecting more then that, nearly 4years later? Some links to get you started: http://php.markmail.org/message/ujx2htvdzerrxgfe?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward http://php.markmail.org/message/n22c6ye5boe2rtjk?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward&page=1 http://php.markmail.org/message/jgsd2umnm5lk37b6?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward&page=1 -Hannes --- ## #47582 — Pierre Joye — 2010-03-24T20:29:12+00:00 URL: https://externals.io/message/47557#47582 · In reply to: #47579 hi Hannes, On Wed, Mar 24, 2010 at 9:10 PM, Hannes Magnusson wrote: > > > […] > > I really do not see why this even needs a discussion. Its been in > trunk for years already. People have had plenty of time to give > feedback. > > Is there really anyone who doesn't want this committed? For what reason? In this case the RFC will help to: - get a clear understanding about the changes - explain how it affects the respective internals area - helps to document the changes effectively But it is really not about finding a reason not to commit this change or discuss again whether or not we want it. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #47583 — Lukas Kahwe Smith — 2010-03-24T20:41:16+00:00 URL: https://externals.io/message/47557#47583 · In reply to: #47581 > > > […] > > Search the archives. Do your homework. > > 3 years and 9 months ago the patch was posted to internals for review. > It included README files, TODO list, tests, tests, tests and explanations. > Few weeks later it got committed. > The commit got reviewed by various parties and some enhancements were made. > Every single procedure was followed to the letter. > People were happy. > > You cannot seriously be expecting more then that, nearly 4years later? All I am asking is a single document in the central location we have dedicated for this (aka the rfc namespace on the wiki), that pulls together all relevant documentation. If all that is needed is a copy paste of a bunch of URL's all the better. But it makes no sense to ask each and every developer to "do his homework". Thats a waste of time and a sure way to have misunderstandings. Seems like you know all there is to know about this, so how about just throwing together an RFC, shouldnt take more than 10 minutes if all of this is already perfectly documented. > Some links to get you started: > http://php.markmail.org/message/ujx2htvdzerrxgfe?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward > http://php.markmail.org/message/n22c6ye5boe2rtjk?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward&page=1 > http://php.markmail.org/message/jgsd2umnm5lk37b6?q=README.NEW-OUTPUT-API+from:%22Michael+Wallner%22+order:date-forward&page=1 These links just highlight that there are questions, not that there are answers. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #47584 — Stanislav Malyshev — 2010-03-24T23:35:08+00:00 URL: https://externals.io/message/47557#47584 · In reply to: #47579 Hi! > I really do not see why this even needs a discussion. Its been in > trunk for years already. People have had plenty of time to give > feedback. > > Is there really anyone who doesn't want this committed? For what reason? I don't think there's a reason not to commit it - but it also would be very nice if we had some good explanation of what happens there, which is in a place where it's easy to find. Not because the patch is bad or something but because it'd be easy to work with it in the future this way. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #47817 — Michael Wallner — 2010-04-07T06:58:35+00:00 URL: https://externals.io/message/47557#47817 · In reply to: #47583 > All I am asking is a single document in the central location we have > dedicated for this (aka the rfc namespace on the wiki), that pulls > together all relevant documentation. If all that is needed is a copy > paste of a bunch of URL's all the better. But it makes no sense to > ask each and every developer to "do his homework". Thats a waste of > time and a sure way to have misunderstandings. > > Seems like you know all there is to know about this, so how about > just throwing together an RFC, shouldnt take more than 10 minutes if > all of this is already perfectly documented. Here you go: http://wiki.php.net/rfc/new-output-api Cheers, Mike --- ## #47818 — Michael Wallner — 2010-04-07T06:59:24+00:00 URL: https://externals.io/message/47557#47818 · In reply to: #47583 > All I am asking is a single document in the central location we have > dedicated for this (aka the rfc namespace on the wiki), that pulls > together all relevant documentation. If all that is needed is a copy > paste of a bunch of URL's all the better. But it makes no sense to > ask each and every developer to "do his homework". Thats a waste of > time and a sure way to have misunderstandings. > > Seems like you know all there is to know about this, so how about > just throwing together an RFC, shouldnt take more than 10 minutes if > all of this is already perfectly documented. Here you go: http://wiki.php.net/rfc/new-output-api Cheers, Mike --- ## #47823 — Zeev Suraski — 2010-04-07T14:37:40+00:00 URL: https://externals.io/message/47557#47823 · In reply to: #47817 At 09:58 07/04/2010, Michael Wallner wrote: >Here you go: > >http://wiki.php.net/rfc/new-output-api Thanks Mike - that's very helpful! Quick question - other than fixing the issues mentioned in the intro section of the RFC, are there any changes to the behavior of userland-accessible functions (ob_start(), etc.)? Zeev --- ## #47829 — Michael Wallner — 2010-04-07T19:56:35+00:00 URL: https://externals.io/message/47557#47829 · In reply to: #47823 Am 07.04.2010 16:37, schrieb Zeev Suraski: > At 09:58 07/04/2010, Michael Wallner wrote: > > […] > > Thanks Mike - that's very helpful! > > Quick question - other than fixing the issues mentioned in the intro > section of the RFC, are there any changes to the behavior of > userland-accessible functions (ob_start(), etc.)? It actually fixes quite some more oddities, but I really can't remember what... I'm also having quite a hard time remembering userland changes, but some off the top of my head: ob_start(array("oh1","oh2","oh3")) does not work, as the handler argument is always supposed to be callable. This was undeocumented anyway. `ob_get_status()` arrays have more/other entries. ob_start("obh", 1) was supposed to really buffer just one byte, but AFAIR this was changed back by someone to default to 4096... `ob_gzhandler()` and thelike are no PHP_FUNCTIONs anymore. Regards, Mike