On 1 November 2014 13:15:45 GMT, Damien Tournoud <d...@damz.org> wrote:
>On Sat, Nov 1, 2014 at 1:40 PM, Andrea Faulds <a...@ajf.me> wrote:
>> > On 31 Oct 2014, at 18:37, Larry Garfield <la...@garfieldtech.com>
>wrote:
>> > IF internals wanted to add implementation, not just improving
>streams, something like the following would be much more useful:
>> >
>> > $request = http_get_request(PHP_STDIN); // or something
>> >
>> > Where $request is an object that implements the PSR-7
>RequestInterface (or at least the read-only parts of it), or something
>similar. Then implementers can compose that object however they want.
>> > [...]
>>
>> This sums up my thoughts on this very well. Nobody needs to change
>how we parse the data. We just need better access to the results of the
>parsing.
>
>Alternatively, what I would see as extremely useful would be to be
>able to expose the "main loop" of the SAPI. Have a way (via an ini
>mechanism) to register a callback that is executed when a requests
>start processing. Essentially, similar to what is provided by WSGI
>(for Python) and Rack (for Ruby).
>
>The default implementation would be something like:
>
><?php
>function default_entrypoint($env) {
> php\register_superglobal($env);
> php\execute_script();
>}
>?>
>
>(with this callback executed in the scope of the new request)
>
>But you could override any of it if you wanted to, and that would pave
>the way nicely to more advanced PHP SAPIs (possibly evented) down the
>road.
This is actually quite an appealing idea; it provides a stepping-stone towards
an evented SAPI without pre-empting other decisions which would need to be made
(such as how global and static scopes would be handled). I particularly like
the idea of exposing elements of default behaviour as non-magic functions, so
that you could pass some other/modified request object to populate
superglobals, for instance.
It could perhaps be implemented as a special function, which if present in the
file targeted by the HTTP request (i.e. not via include()/require()) is called
automatically, and passed a standard object providing access to the raw request.
I'm not sure how the response could best be managed so that it interacted
smoothly with existing mechanisms; the function could optionally return a
response object, but would perhaps need access to a magic object representing
the default response built with echo, header_*() etc. Waiting for the entire
response to be ready before streaming it to the SAPI isn't always desirable,
either; I guess these are the kinds of issue FIG have been discussing...
In short, though, you would have an index.php file something like this:
<?php
function __main(HTTPRequst $request, HTTPResponse $default_response) {
require 'autoloader.php';
$action = Router::selectAction($request->getQueryStringParam('action'));
$custom_response = $action->process($request);
return $custom_response;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
