Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51054
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.45 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=Z/9G60LC6J53Tu/e/gTdp26hVWOBZ+DMLsI8n8XILE2lYfKly3yBhmsfCXCbrk0SVl
         z50kV3QY3F0WuzewL5gHVaSiE1w7INDkoxfL3GEyjseYopAQtVpICkAyTgAYhMLj2QYT
         FXhfhfM2g94IWLiYScdNHInZkDd7N3Y8BewCA=
MIME-Version: 1.0
In-Reply-To: <AANLkTimOzxp87V0WXG5uag1ts4snHf2hCpx5RBVqMOd+@mail.gmail.com>
References: <op.vnb0shjiidpuyk@damnation.dulce.lo.geleia.net>
	<op.vngrk2s3idpuyk@damnation.dulce.lo.geleia.net>
	<AANLkTintNBB_NGbxWNyGFDm5sJh1_L+1PqaGty45GJjG@mail.gmail.com>
	<AANLkTi=yk3fkz5Q-8Etw88mg1UDm-oLzB7wz0e65zZRB@mail.gmail.com>
	<AANLkTikY7OUZJSfkHXr2jTnA3_c0SaQ6u=d1qhgn6reF@mail.gmail.com>
	<6b2ba5e56d64910c49bb431ba1e36e17@nebm.ist.utl.pt>
	<AANLkTi=UMr3nK10dg8_2zrcgvnyJ6ES9vdEsFgJgZZaR@mail.gmail.com>
	<EF.71.36789.F9F1A0D4@pb1.pair.com>
	<AANLkTikePQafwzN8gcmtVExYVjO_R2Ht-qFZf3dSAExW@mail.gmail.com>
	<59.E3.36789.3D72A0D4@pb1.pair.com>
	<AANLkTimOzxp87V0WXG5uag1ts4snHf2hCpx5RBVqMOd+@mail.gmail.com>
Date: Thu, 16 Dec 2010 16:10:52 +0100
Message-ID: <AANLkTik7+eoj9dKT=gTdiB0W_b-O7Ewy_LG9xMYorWNF@mail.gmail.com>
To: "Matthew Weier O'Phinney" <weierophinney@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001636c5b067b522ac0497887564
Subject: Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
From: pierre.php@gmail.com (Pierre Joye)

--001636c5b067b522ac0497887564
Content-Type: text/plain; charset=ISO-8859-1

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&apos;Phinney" <weierophinney@php.net>
wrote:

On 2010-12-16, Pierre Joye <pierre.php@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 | matthew@zend.com
Zend Framework | ht...

--001636c5b067b522ac0497887564--