Re: Named output buffers

I still fail to see how this is beneficial. Are you aware of the existing mechanism? Currently, you can call ob_start() several times, and the output buffering system transparently works with a stack of output buffers. You can also register a callback function that will be executed when output buffering ends, instead of plainly sending out the buffer, if you wish. A stack in this case makes much more sense than a 'random access', named mechanism. Where does the output go when you open two output buffers? What happens if you close the 1st one (outermost) before the 2nd? The current system allows you to write reusable functions, that don't rely on any specific context. Adding random access seems a bit like a mess to me. By the way, saving the output buffer in a variable makes much more sense than adding a new symbol table to the output buffering mechanism. Zeev At 21:13 13/09/2000, Chuck Hagenbuch wrote:

Quoting Zeev Suraski <zeev@zend.com>:

Oooh, that would be _very_ useful!

How? If you're using the output buffer support for xslt, or to compress content, or something else that requires capturing all of the page output, being able to use a seperate buffer to capture the output of things like highlight_string, fpassthru, or other functions that normal output straight to the browser would be great... As it stands now, you need to save the contents of the output buffer in a variable, then do your stuff, then reset it... not to mention checking to see if it's even being used yet... -chuck -- Charles Hagenbuch, <chuck@horde.org> -- "Alice found a niche in the market for her diabolically malodorous rabbit pellet."

-- Zeev Suraski <zeev@zend.com> http://www.zend.com/