I think you over react due to our past mistakes. What I'm trying to explain is exactly what you want. Efficienty without cinfusionsconfusions, ugly hacks or features duplication.
And that's what I would like to discuss here instead if just doing it, for the sake of doing it. On 16 Dec 2010 15:53, "Matthew Weier O'Phinney" <weierophin...@php.net> wrote: On 2010-12-16, Pierre Joye <pierre....@gmail.com> wrote: > On Thu, Dec 16, 2010 at 3:18 PM, Matthew ... > > The only way I can see such an action being "sensible" is if it's also > > runtime configurable ... INI_PER_DIR doesn't work for, I would argue, the majority of modern PHP applications. If you look at most frameworks, CMS solutions, or standalone apps such as WordPress, there's a single script acting as the gateway to all functionality (basically, a front controller). Making the setting INI_PER_DIR means that you have to move any functionality that may potentially require access to raw POST/PUT data into separate scripts and/or directories -- which splits functionality away from the front controller and makes maintenance much more difficult. > All in all, I don't think adding a set of new ini settings for very > specific and disputable fea... I'm not talking about processing file uploads; I'm talking about normal handling of raw POST/PUT body content -- something that's very, very common when dealing with RESTful or RPC APIs, where the format isn't normal URL encoding, but instead something like XML or JSON. I'm all for better, more efficient processing of file uploads -- but not at the expense of being able to build good APIs. -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | ht...
