Am 31.03.2015 um 19:09 schrieb Grégory Planchat: > Possible solutions would be : > 1. About multiplexing : > 1.a. integrate php-uv in the core in its current form and let > developers implement their own protocol layer > 1.b. transform some project like ReactPHP into an extension (using > Zephir and/or native C) > 1.c. create a new SAPI or extend an existing one, which woud offer the > possibility of manipulating the resource multiplexing queue. PHP would > still be in the Apache2/CGI stack, but would notify the server to send a > resource list
I really don't see what action there is to take for PHP with regards to multiplexing. Currently, Apache seems not to support HTTP/2, other servers I don't know. But when Apache will support HTTP/2, multiplexing will most likely work similar to how it worked with SPDY (the predecessor to HTTP/2). You just send an additional header containing the files you want the server to provide to the client. mod_spdy used the X-Associated-Content-Header (see https://code.google.com/p/mod-spdy/wiki/OptimizingForSpdy) "More" multiplexing will mean multiple parallel execution paths within the engine but that kind of parallelism introduces a hell of concurrency problems nobody truly wants. > 2. About push: same as 1.a. and 1.b. Push can only work with long running PHP processes. I kind of agree a stable PHP daemon process mode/SAPI would be nice. That mode would be similar to a WebSockets mode which we should get in the future. But that has nothing to do with HTTP/2 from my perspective. Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
