Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69539
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
Message-ID: <5255C886.50801@garfieldtech.com>
Date: Wed, 09 Oct 2013 16:20:06 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; 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> <5252CD5B.1090202@gmail.com>
In-Reply-To: <5252CD5B.1090202@gmail.com>
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: larry@garfieldtech.com (Larry Garfield)

On 10/7/13 10:03 AM, Rowan Collins wrote:
> 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,

The Framework Interoperability Group has been discussing a unified 
request/response spec on and off for a while.  There's definite interest 
in having one, especially if it can support HTTP clients (Guzzle and 
Buzz, etc.) with the same interface as the main PHP process.

I'd actually recommend those who are interested work on it over there, 
let it happen in PHP user space, and then later backport it to C code if 
it seems to work out well.

--Larry Garfield