Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69505
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.50 as permitted sender)
Message-ID: <5252CD5B.1090202@gmail.com>
Date: Mon, 07 Oct 2013 16:03:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: internals@lists.php.net
References: <CALJZF3hq1FVTJUGwq9PAt+6joDhmuoXPR9Z8cxTPvafUmek9wg@mail.gmail.com>  <1380723023.19591.24.camel@guybrush>  <CALJZF3g9WaXADPfBYgn5FQCv7njcpSRgo0gERbjYCirvbx0maQ@mail.gmail.com>  <1380750003.19591.55.camel@guybrush>  <l2n1te$q26$1@ger.gmane.org> <1381144884.10732.31.camel@guybrush>
In-Reply-To: <1381144884.10732.31.camel@guybrush>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing
 PUT data)
From: rowan.collins@gmail.com (Rowan Collins)

Hi All,

Johannes Schlüter wrote (on 07/10/2013):
> Why replace something? Are there flaws which can't be fixed? Adding too
> many ways to do the same thing is confusing for everybody. If you want
> it "object oriented" or such frameworks do great things. The language
> should offer a good foundation. (It is my strong believe that we should
> move as many "high level" things as possible in libraries)

I think this is a strong point: PHP as it is now is a long way from 
being usable as a modern framework in its own right, and building a 
framework-like API for this kind of functionality may open a bigger can 
of worms than was intended. Zend, Symfony, et al have a massive 
head-start on any kind of "PHP native framework".

Rather than trying to build the framework logic into the core, how about 
exposing the functionality currently in core to user-space so that 
frameworks can wrap it more efficiently? Looking around, we currently 
have the slightly awkward parse_str for query strings and 
application/x-www-form-urlencoded bodies; I imagine there's something in 
pecl_http for multi-part/form-data, but I'm not familiar with that 
extension, and it's not part of core.

If the internal implementations were decoupled from the population of 
$_POST as a consistent set of functions, frameworks could simply wrap 
them alongside custom parsers such as JSON (with appropriate options) or 
XML (restricted to some framework-defined schema). This also allows for 
simulated requests, unit testing, etc, and passing in 
file_get_contents('php://input') should allow parsing any request body. 
If this was done as some consistent "serialization/deserialization" 
module, it could expose the session serialization formats as well, 
replacing the horrible environment-clobbering of session_decode().

Regards,
-- 
Rowan Collins
[IMSoP]