Re: [PHP-DEV] Naming of 'weak' type hints
On 30/03/15 15:16, Zeev Suraski wrote: Personally I think we should go for ‘dynamic’ when we document it, as this is the common way to refer to this behavior (dynamic languages). We could also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’, although I think we can easily do without introducing a new word into the vocabulary here. soft and hard? And as long as we don't add any hints it is still 'no type hinting' ? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP 7
On Tue, Mar 31, 2015 at 3:02 PM, Tony Marston tonymars...@hotmail.com wrote: Nikita Popov wrote in message news:CAF+90c9ZCE4rrdtwoqwnBE=u_s4asxhu4n_jia+40oy_gum...@mail.gmail.com... On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I was never happy about this particular hack but that said, unless we *know* it is not used widely (and I suspect it is in Japan etc. where we don't have a lot of visibility due to language barrier) we can't really remove it. Also, I'm not sure why should we remove it. Yes, it's a PITA for the code, but looking at it in another direction, it is only a PITA if people actually turn it on, which means they're using it (otherwise why turn it on?). Deprecating it may be ok provided we actually have some proposal as to what people should do instead. If we have consensus on deprecating it, I don't think it's a problem have it done in 7.0 since it's not a substantial code/feature change and beta period provides ample time for people to scream if it's unacceptable. If there's no consensus yet, I'd go for 7.1. From this thread, I'd say we have a consensus to deprecate it. From the Japanese side, both Yasuo and Masaki agree that this should be dropped and Masaki also linked a bug report where it is stated that the original author of this functionality agrees that this should be deprecated. It also contains a link to a discussion on a Japanese PHP dev ML, where, as far as Google Translate can tell me, everyone agreed that that we should do away with it. As to what people should use instead: For the quick hack to make things work: a sed script. Apart from that, implementing proper multibyte handling in applications. Nikita But what is proper multibyte handling? Where is it documented? Just to be sure it is clear: We are not talking about deprecating the mbstring extenson, not at all. What we refer to is about deprecating the PHP functions overloading in mbstring. This can be enabled using: http://php.net/manual/en/mbstring.configuration.php#ini.mbstring.func-overload and http://php.net/manual/en/mbstring.overload.php So far, I know nobody outside the original authors actually using it. And I asked quite a lot of companies and devs around here (hint, Asia). Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Naming of 'weak' type hints
On Mon, Mar 30, 2015 at 4:16 PM, Zeev Suraski z...@zend.com wrote: All, One thing that I think we should change is how we refer to the ‘weak’ type hints. The word ‘weak’ has a negative ring to it, and considering this is how the language behaves across the board it’s a pretty bad name for this feature. Personally I think we should go for ‘dynamic’ when we document it, as this is the common way to refer to this behavior (dynamic languages). We could also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’, although I think we can easily do without introducing a new word into the vocabulary here. Thoughts? Zeev Hello, I would definitely stick with weak; it is common naming used across many languages and textbooks. Also, why is the strongly typed mode named strict anyways? If anything should change, it should be strict to strong, so PHP doesn't look like a special snowflake. Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes
Hi Dan, any update? should I commit it? or do you see any problems? Thanks. Dmitry. On Mon, Mar 30, 2015 at 7:06 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Dan, The updated patch is at https://github.com/php/php-src/pull/1205 The main difference is in ext/intl. If you don't see any problems I can commit it. I didn't think about the classes you missed. Thanks. Dmitry. On Fri, Mar 27, 2015 at 7:32 PM, Dan Ackroyd dan...@basereality.com wrote: On 26 March 2015 at 20:19, Dmitry Stogov dmi...@zend.com wrote: Hi Dmitry, however the patch looks a bit surprising to me. We have special function to do this - zend_ctor_make_null() and some tricks in the VM. I made just a quick look over your patch but didn't find any references to them. Surprising is usually not good, so let me see if I can explain. I touched the minimal amount of code needed to achieve the desired behaviour. For the intl classes, the exception is being thrown by telling the intl error handling code to use an exception, no matter what the intl.use_exceptions setting is, if the error was emitted during a constructor: https://github.com/Danack/php-src/blob/InternalClassClean/ext/intl/intl_error.c#L114 I didn't touch any of the code zend_ctor_make_null. I guess if it's only used in these special cases, and they are going away it could also be removed? But it sounds like that would be a job for someone who understands that bit. Please don't commit it yet. That won't be difficult, I don't have commit rights, and don't particularly want them. Nikita, could you also take a quick look. Nikita pointed out that I may have missed a couple of classes. I'll try to get those updated before you have a look. cheers Dan
Re: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP 7
Nikita Popov wrote in message news:CAF+90c9ZCE4rrdtwoqwnBE=u_s4asxhu4n_jia+40oy_gum...@mail.gmail.com... On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I was never happy about this particular hack but that said, unless we *know* it is not used widely (and I suspect it is in Japan etc. where we don't have a lot of visibility due to language barrier) we can't really remove it. Also, I'm not sure why should we remove it. Yes, it's a PITA for the code, but looking at it in another direction, it is only a PITA if people actually turn it on, which means they're using it (otherwise why turn it on?). Deprecating it may be ok provided we actually have some proposal as to what people should do instead. If we have consensus on deprecating it, I don't think it's a problem have it done in 7.0 since it's not a substantial code/feature change and beta period provides ample time for people to scream if it's unacceptable. If there's no consensus yet, I'd go for 7.1. From this thread, I'd say we have a consensus to deprecate it. From the Japanese side, both Yasuo and Masaki agree that this should be dropped and Masaki also linked a bug report where it is stated that the original author of this functionality agrees that this should be deprecated. It also contains a link to a discussion on a Japanese PHP dev ML, where, as far as Google Translate can tell me, everyone agreed that that we should do away with it. As to what people should use instead: For the quick hack to make things work: a sed script. Apart from that, implementing proper multibyte handling in applications. Nikita But what is proper multibyte handling? Where is it documented? -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Stanislav Malyshev wrote on 30/03/2015 23:10: Hi! If an organisation has standardised on an old version of PHP, there's a By old you're meaning current stable, I presume. No, current stable is 5.6.x; people have been talking about backporting to 5.5.x (which has 2 months of active support remaining according to http://php.net/supported-versions.php). fair chance that the builds they are using are not from php.net, but from their OS distribution. As has been mentioned here before, these There are no builds on php.net, except for windows.php.net. Most organizations I've encountered indeed use either distros or their own distro-like packages (which usually mimick distro ones but have modifications like additional packages, tweaking paths, adding/removing configs or data, etc.). Yes, builds is perhaps not the right word, but you got my meaning OK. generally track a particular patch release and cherry-pick fixes - Ubuntu 14.04 maintains a patched version of PHP 5.5.9 vs the official 5.5.23, for instance. Anyone working in such an environment won't receive the benefit of a new feature however far it is backported. As per above, it's much easier to get 5.5.23 installed in the org than 7.1. I'm not overly familiar with particulates of Debian policies, but if they have whole distro sitting on 5.5.9 when there's 5.5.23 out it's bad, as their customers do not get bugfixes which may be essential for them. I sincerely hope it's not the case. In any case, burden of creating 5.5.23 package from debian 5.5.9 package is very low, most competent ops would be able to do this, and That's not quite how it works; the distro package maintainers maintain a sort of forked version of upstream code, combining a well-tested upstream release with a set of patches, many of which will be backported fixes from newer releases. So the current package in Ubuntu 14.04 LTS [see http://packages.ubuntu.com/trusty/php5] is 5.5.9+dfsg-1ubuntu4.7, and the Ubuntu Changelog shows 12 releases, mostly for security patches, which is nearly as many as there have been upstream releases. the risk of following 5.5 line is not comparable to the risk of switching from 5.5 to 7.1. This is a straw man as far as the points I made are concerned. I'm talking about the risk of switching from 5.5 to 5.6, which is pretty low. The obvious alternative avenues are to write a forward-compatible userland version, or package an extension, both of which are likely to reach a larger audience than a tail-end release like 5.5.23. I'm not sure how you mean to write an extension that would add an option to json_encode for example. Well, you could fork the JSON extension, I guess. But yes, not all options are available in all cases. I can certainly see value in a special case for including things in both 5.6 and 7.x, both before and after 7.0 is released, but the the case for backporting anything other than a genuine bug fix to 5.5.x right now seems fairly weak, as will the case for backporting to 7.0.x after 7.1.0 is released (by which point 5.6.x will presumably be in its security-only phase). That means right now any enhancement somebody would propose would be just released somewhere towards the end of next year. And since nobody switches instantly, especially to the next major, their timeframe to use it would be something like 4-5 years. I would have zero motivation as a userland developer to work on a small change like adding an option that I could benefit from in 5 years maybe. Would you? That's completely the opposite of what I said. I said I *do* think adding small features to 5.6 may be justified, since 7.0 will be a more painful upgrade. The type of backporting I'm questioning is adding features to 5.5.x, when we have 5.6.x released, and 7.0.x in preparation. And, *after* the 7.1.0 release towards the end of next year, I would not expect features to be backported to 7.0. The problem is that there is no way to know, as a user, which function names may become reserved in the future. There is an officially reserved That's true in general. But if you name your function something like get_error_handler or mysql_connect_something, you must know you're on a shaky ground. The argument we can not add anything in the main namespace because somebody could have named function exactly the same sounds hollow to me. Of course, for some cases it must be true, but most people that don't use classes long learned to prefix or namespace their functions, and And, of course, this does not apply to adding options, etc. No, indeed. There, the cost is only on the developer having to ensure that they don't deploy code relying on the new option to a server one patch version too old. reserved. I don't think it's at all insane to say that a patch version shouldn't usurp non-reserved names. I think in this form it is. There are no reserved names in functions, and if you use mysql_* namespace functions and it clashes with
Re: [PHP-DEV] JSON float number as string
Hi Jakub, On Mon, Mar 30, 2015 at 5:45 PM, Jakub Zelenka bu...@php.net wrote: On Mon, Mar 30, 2015 at 1:07 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: int should be fixed also. http://3v4l.org/95dHM We have already fix for this: JSON_BIGINT_AS_STRING ( http://3v4l.org/vYXUk ) Excellent. So option may be JSON_SCALAR_AS_STRING or additional JSON_INT_AS_STRING. I was actually thinking about JSON_INT_AS_STRING anyway as it might be useful for type consistency in decoding (when decoding number that are close to bigint limit) and allowing safe encoding from 64bit to 32bit. However this is a bit more controversial so I plan to open a new thread about it. There are too many options (4 options to be exact) for JSON to work safely under HTML context currently. If user would not like to loose int/float information, 6 options are needed. Number of options are better to be reduced, so big +1 for string raw data by default. It may be better to have JSON_HEX_HTML_CHARS = JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT also. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Backwards compatibility with set_exception_handler callback and type hints
That is a stellar response Dan, Thanks for being so clear. I had a feeling
that this might be the case so we'll have to work around it.
Just for clarity and posterity I provided the simplest test case in the
original email not the actual problem. In Drupal this isn't just one place
though becase, we have a library(and by library I mean class) for parsing
information out of exceptions. So we would have to do quite a bit more
hackery then that to to keep type hinting.
On Tue, Mar 31, 2015 at 8:59 PM, Dan Ackroyd dan...@basereality.com wrote:
Hi James,
On 31 March 2015 at 21:51, James Gilliland neclim...@gmail.com wrote:
By design, \EngineException does not extend \Exception so code doesn't
accidentally catch this special type of exception. ...
I don't know if this is all acceptable and/or by design but it is awkward
so I wanted to bring it to the list to discuss.
Let me try to explain why the BC break at the top level is the right
choice.
The change in the Exception hierarchy has to cause a BC break to exist
'somewhere', as errors in code that were previously not throwing an
exception, but in effect just doing exit() are now throwing an
exception. This is a change in behaviour that cannot be handled
without some sort of BC break.
There are two types of places where \Exception are currently being caught:
i) in the middle of applications where some library is being called
where all exceptions need to be caught and changed to a more specific
exception.
function foo() {
try {
someOtherLibrary();
}
catch (\Exception $e) {
throw new OtherLibraryException(
$e-getMessage(),
$e-getCode,
$e
);
}
}
ii) At the top level of the application where all exceptions are being
caught, so that they can be logged and a more graceful error message
than a stack trace can be shown to the user.
If the BC break was for (i) by making all of the new exceptions be
under the hierarchy of \Exception, it would result in a lot of BC
break spread out across applications.
Having the BC break in (ii) is pretty strongly preferable; it means
that there are just a few (or one), easy to find places in an
application where the code now needs to be changed from catching
\Exception to catching \BaseException (or whatever it will be after
the exception tidy up).
Drupal (or any other application) can handle this BC break reasonably
easily by either dropping the type from the parameter of
_default_exception_handler or by adding a version check around it's
declaration like:
if (PHP_VERSION_ID = 70) {
function _default_exception_handler(\BaseException $e) {
}
}
else {
function _default_exception_handler(\Exception $e) {
}
}
Yeah, this isn't the most awesome thing ever to have to do, but imo it
sure beats having to change code in the middle of applications.
cheers
Dan
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Am 31.03.2015 22:45 schrieb Rowan Collins rowan.coll...@gmail.com: - Up until the first release candidate of x.y.0, small features can be added to both the most recent live branch and the new branch being prepared for release (so, right now, 5.6.x and 7.0-pre; next summer, 7.0.x and 7.1-pre). - Once a new x.y.0 release is ready, x.y-1.z releases should receive bug fixes only. Thus 5.5.x should not be receiving features. - As an exception to the above, when releasing x.0.0, the previous branch may continue receiving small features, until it reaches the end of its active support phase. In other words, keep backporting things to 5.6.x after 7.0.0 is released, since adoption of the latter is likely to be slow. By the time 7.1.0 comes around, active support for 5.6 will have ended anyway, unless we make some other exception to the normal process. This is very much a compromise between the SemVer ideal of a patch release, and the practical implications of a yearly release cycle. The aim is to make it obvious to users what they'll get in return for upgrading, and to smoothly transition a branch from cutting edge to stable with bug fixes, then to security only and end of life. What do people think? That sounds very reasonable, and would suit me fine :) One issue that I think speaks for such an approach, is giving new-small-features better exposure outside of developer circles. If features only ever go into the-next-tree, they won't be seen and tried out in the field until after that is committed as a new-stable release. The feature also probably can't be added to the php.net documentation until that release happens (right). Lots less eyes seeing it, finding problems with it that might be rectified before next-becomes-stable. I think there's a three layer hierarchy of adoption at play here, which also can explain the low adoption figures of newest-stable. At the top, you have next-stable, which will be visible almost exclusively to contributors, and won't get any real world production exposure at all. Then you have the current stable, which is used by shops (like mine...) that care about building their own binaries, and that have a rather homogenous inhouse codebase that can evolve to use new major and minor features in production. And then there's the vast field which runs on distribution builds, which seems to sit on the oldest supported stable version in existence until it's faded out, and which doesn't care about new features at all. Do I make sense? :) best regards Patrick
Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes
Hi Dmitry,
Your approach is definitely a better one, and I have no objection to
it whatsoever.
Sorry, I was too busy to look deeply at each class but I can't see any problems.
Nikita Popov wrote:
does that mean that the same code using strict_types=1 mode will start
throwing TypeException instead of whatever exception type is passed
to replace_error_handling?
That's going to affect everything isn't it - not just this RFC?
However I think that is the correct behaviour. It more closely
resembles the behaviour that will be seen in userland code, and is
more 'semantically' meaningful i.e. it allows people to tell the cases
between the two types of errors apart.
It probably bears more thinking about though.
cheers
Dan
$formatInfoList = [
[en_US, {0,number,integer} monkeys on {1,number,integer} trees
make {2,number} monkeys per tree],
[en_US, '{this was made intentionally incorrect}'], //valid type
but wrong value
[en_US, new StdClass] //wrong type
]
foreach ($formatInfoList as $formatInfo) {
list($locale, $pattern) = formatInfo;
try {
$mf = new MessageFormatter($locale, $pattern);
echo $mf-format(array(4560, 123, 4560/123));
}
catch(IntlException $ie) {
// A strict type-est person would not want this to catch the case where
// the wrong type has been passed, as it's not an exception
related to Intl
// it's an exception related to the type being wrong.
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Backwards compatibility with set_exception_handler callback and type hints
Hi James,
On 31 March 2015 at 21:51, James Gilliland neclim...@gmail.com wrote:
By design, \EngineException does not extend \Exception so code doesn't
accidentally catch this special type of exception. ...
I don't know if this is all acceptable and/or by design but it is awkward
so I wanted to bring it to the list to discuss.
Let me try to explain why the BC break at the top level is the right choice.
The change in the Exception hierarchy has to cause a BC break to exist
'somewhere', as errors in code that were previously not throwing an
exception, but in effect just doing exit() are now throwing an
exception. This is a change in behaviour that cannot be handled
without some sort of BC break.
There are two types of places where \Exception are currently being caught:
i) in the middle of applications where some library is being called
where all exceptions need to be caught and changed to a more specific
exception.
function foo() {
try {
someOtherLibrary();
}
catch (\Exception $e) {
throw new OtherLibraryException(
$e-getMessage(),
$e-getCode,
$e
);
}
}
ii) At the top level of the application where all exceptions are being
caught, so that they can be logged and a more graceful error message
than a stack trace can be shown to the user.
If the BC break was for (i) by making all of the new exceptions be
under the hierarchy of \Exception, it would result in a lot of BC
break spread out across applications.
Having the BC break in (ii) is pretty strongly preferable; it means
that there are just a few (or one), easy to find places in an
application where the code now needs to be changed from catching
\Exception to catching \BaseException (or whatever it will be after
the exception tidy up).
Drupal (or any other application) can handle this BC break reasonably
easily by either dropping the type from the parameter of
_default_exception_handler or by adding a version check around it's
declaration like:
if (PHP_VERSION_ID = 70) {
function _default_exception_handler(\BaseException $e) {
}
}
else {
function _default_exception_handler(\Exception $e) {
}
}
Yeah, this isn't the most awesome thing ever to have to do, but imo it
sure beats having to change code in the middle of applications.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
Andrey Hristov wrote on 31/03/2015 16:02: Currently in MT environment the task of data separation is pushed to the TSRM by using TLS. Now, if TSRM is reimplemented in a fashion that the data is not stored by using TLS but other mechanism and cooperative multitasking is not something that can't be done. The truth is that userland is isolated from the process data space so for it it won't make a difference. It's just that using threads for separation is the easiest thing (after process per script). The good thing is that TSRM is an abstraction for its clients. Isn't the point that to get a real advantage from these technologies, the *userland* needs to be aware of threads / events? That's what requires a fundamental rethink of the language. TSRM/TLS allows you to drop from one-process-per-request to one-thread-per-request, but it doesn't save you the expense of repeatedly building up and tearing down an execution environment. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
Le 31/03/2015 15:56, Daniel Lowrey a écrit : HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently exists. The protocol impacts the actual HTTP server and has nothing to do with the SAPI runtime which is simply handed information about the HTTP request once the server parses it. The protocol used to communicate those details between the client and the HTTP server does not concern the web SAPI. There is no need for any sort of support for h2 in PHP; it's the web server's concern. Apache and nginx will add support for h2 and PHP will continue working as it always has. That said, the php web SAPI derives exceedingly little benefit from the advent of HTTP/2.0. h2 is designed to allow multiplexing of many requests over the same TCP connection but the PHP web SAPI still has the same bottleneck it had before h2: one thread/process per request. As for websockets, you *can* do that using the web SAPI right now if you wished but this would be inadvisable because long-lived connections will quickly fill the bottleneck in every PHP web application (concurrent threads/processes for each request). Instead, the appropriate solution for websockets would be to implement a socket server directly in the CLI that speaks the websocket protocol. Would it be useful to have raw incremental parsing functionality for HTTP/1.1, HTTP/1.2 and websocket protocols available in userland? Sure, but this falls more in the realm of an extension than anything else as few people are implementing full-blown http and websocket servers in the CLI right now. Hi Daniel, Your message is focusing on the solution I can find today in the wild, not about the need mys previous message was about, namely multiplexing and message push. Anyway I'm aware of this and I understand your point, but why should'nt we be able, natively, to exploit HTTP/2 enhancements, particurlarly resources multiplexing and data push? Why woud we restrain to exploit 20 years old protocol features, deliberately omitting new ones that are already implemented on other platforms? Grégory -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently exists. The protocol impacts the actual HTTP server and has nothing to do with the SAPI runtime which is simply handed information about the HTTP request once the server parses it. The protocol used to communicate those details between the client and the HTTP server does not concern the web SAPI. There is no need for any sort of support for h2 in PHP; it's the web server's concern. Apache and nginx will add support for h2 and PHP will continue working as it always has. That said, the php web SAPI derives exceedingly little benefit from the advent of HTTP/2.0. h2 is designed to allow multiplexing of many requests over the same TCP connection but the PHP web SAPI still has the same bottleneck it had before h2: one thread/process per request. As for websockets, you *can* do that using the web SAPI right now if you wished but this would be inadvisable because long-lived connections will quickly fill the bottleneck in every PHP web application (concurrent threads/processes for each request). Instead, the appropriate solution for websockets would be to implement a socket server directly in the CLI that speaks the websocket protocol. Would it be useful to have raw incremental parsing functionality for HTTP/1.1, HTTP/1.2 and websocket protocols available in userland? Sure, but this falls more in the realm of an extension than anything else as few people are implementing full-blown http and websocket servers in the CLI right now.
[PHP-DEV] Naming of 'weak' type hints
On Monday, March 30, 2015, Christoph Becker cmbecke...@gmx.de javascript:_e(%7B%7D,'cvml','cmbecke...@gmx.de'); wrote: It appears to me that all of these suggestions may hide the fact that the arguments are converted to the hinted types. So perhaps converting type hints might be a good name. Coercive may be a concise term, without the negative connotation of weak/lax. -- jeremy mikola
[PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
On Tue, Mar 31, 2015 at 10:11 AM Grégory Planchat greg...@luni.fr wrote: Le 31/03/2015 15:56, Daniel Lowrey a écrit : HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently exists. The protocol impacts the actual HTTP server and has nothing to do with the SAPI runtime which is simply handed information about the HTTP request once the server parses it. The protocol used to communicate those details between the client and the HTTP server does not concern the web SAPI. There is no need for any sort of support for h2 in PHP; it's the web server's concern. Apache and nginx will add support for h2 and PHP will continue working as it always has. That said, the php web SAPI derives exceedingly little benefit from the advent of HTTP/2.0. h2 is designed to allow multiplexing of many requests over the same TCP connection but the PHP web SAPI still has the same bottleneck it had before h2: one thread/process per request. As for websockets, you *can* do that using the web SAPI right now if you wished but this would be inadvisable because long-lived connections will quickly fill the bottleneck in every PHP web application (concurrent threads/processes for each request). Instead, the appropriate solution for websockets would be to implement a socket server directly in the CLI that speaks the websocket protocol. Would it be useful to have raw incremental parsing functionality for HTTP/1.1, HTTP/1.2 and websocket protocols available in userland? Sure, but this falls more in the realm of an extension than anything else as few people are implementing full-blown http and websocket servers in the CLI right now. Hi Daniel, Your message is focusing on the solution I can find today in the wild, not about the need mys previous message was about, namely multiplexing and message push. Anyway I'm aware of this and I understand your point, but why should'nt we be able, natively, to exploit HTTP/2 enhancements, particurlarly resources multiplexing and data push? Why woud we restrain to exploit 20 years old protocol features, deliberately omitting new ones that are already implemented on other platforms? Grégory You're right -- I was addressing the status quo. The issue here is this: the web SAPI is historically the most stable thing about PHP. Supporting things like message push and multiplexing would require a fundamental change in what the web SAPI is. You would have to junk the entire model and create something completely new. It wouldn't be PHP anymore because you couldn't use the thread/process per-request model; users could no longer rely on the ease and simplicity of every function call being a simple synchronous operation. This kind of major paradigm shift is something that couldn't remotely be considered for PHP7. Even if it were possible you have to consider the web SAPI's target demographic. This demographic knows nothing about non-blocking IO and multitasking. I used to be a proponent of integrating things like this directly into the core of PHP. However I no longer consider this to be a good idea. Why? Because all of the functionality needed to implement these things yourself is available in extensions *right now.* I've personally worked on a closed-source userland non-blocking HTTP+websocket server over the last couple of years that clears 80,000 requests per second with 10,000 simultaneous clients running PHP7 on a single box with an i2600K cpu. Instead of massively changing the fundamental nature of the PHP web SAPI I believe we should focus on improving PHP as a language and not a web framework. By doing so we make it increasingly possible to implement things like this directly in userland with good performance. This can be accomplished right now by simply focusing on extension development (like php-uv which you mentioned and I've contributed to myself). Would I personally prefer to re-implement everything in PHP on top of libuv and bake non-blocking and threaded concurrency directly into the language with async functions and promises? Absolutely. But you're talking about a massive amount of work here. In standard internet parlance ... ain't no one got time for that.
[PHP-DEV] Re: Re: HTTP/2 and Websocket support in 7.x versions
this ain't exactly true. Currently in MT environment the task of data separation is pushed to the TSRM by using TLS. Now, if TSRM is reimplemented in a fashion that the data is not stored by using TLS but other mechanism and cooperative multitasking is not something that can't be done. The truth is that userland is isolated from the process data space so for it it won't make a difference. It's just that using threads for separation is the easiest thing (after process per script). The good thing is that TSRM is an abstraction for its clients. How could we make this work in the absence of TSRM, though? I'm operating under the assumption that any solution would need to work the same way outside the auspices of TSRM. With process forking you'd be talking about pretty complex inter-process signaling to try and accomplish equivalent multitasking. This doesn't seem at all feasible to me on first glance (though I've been wrong plenty of times in the past).
Re: [PHP-DEV] Naming of 'weak' type hints
Pavel, Hello, I would definitely stick with weak; it is common naming used across many languages and textbooks. Also, why is the strongly typed mode named strict anyways? If anything should change, it should be strict to strong, so PHP doesn't look like a special snowflake. Strong has a very specific meaning, which PHP is not using. For example, Python variables are strongly typed (meaning it's restrictive about how types are intermingled). So while x + 3 in JavaScript (another weakly typed language) is x3, in python it would be a type error (assuming x + 3). PHP's overall type behavior is still weak at the variable level. The difference is that strict type declarations require types to match at the point of parameter passing. But it doesn't make the variable strongly typed. As far as weak, that's the description of the type system in general. However as far as type declarations are concerned, I think it would be fair to talk about the two modes as coercive and strict. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! - Up until the first release candidate of x.y.0, small features can be added to both the most recent live branch and the new branch being prepared for release (so, right now, 5.6.x and 7.0-pre; next summer, 7.0.x and 7.1-pre). - Once a new x.y.0 release is ready, x.y-1.z releases should receive bug fixes only. Thus 5.5.x should not be receiving features. - As an exception to the above, when releasing x.0.0, the previous branch may continue receiving small features, until it reaches the end of its active support phase. In other words, keep backporting things to 5.6.x after 7.0.0 is released, since adoption of the latter is likely to be slow. By the time 7.1.0 comes around, active support for 5.6 will have ended anyway, unless we make some other exception to the normal process. This looks like a reasonable compromise. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
Le 31/03/2015 16:40, Daniel Lowrey a écrit : The issue here is this: the web SAPI is historically the most stable thing about PHP. Supporting things like message push and multiplexing would require a fundamental change in what the web SAPI is. You would have to junk the entire model and create something completely new. It wouldn't be PHP anymore because you couldn't use the thread/process per-request model; users could no longer rely on the ease and simplicity of every function call being a simple synchronous operation. This kind of major paradigm shift is something that couldn't remotely be considered for PHP7. Even if it were possible you have to consider the web SAPI's target demographic. This demographic knows nothing about non-blocking IO and multitasking. I'm not saying that we should drop the current web SAPIs to the ground, I'm just advancing the idea of enhancing it or find some other way - in parallel of existing SAPIs - to bring these functionalities, maybe a specific SAPI. CLI SAPI is already using an unique RINIT/RSHUTDOWN cycle, programs such as ReactPHP or the one I built with php-uv -and probably the one you mentioned building yourself- suffers from brutal crashes on fatal errors and does not take benefit from the request isolation. These issues will be indirectly and partially addessed with the ZE now sending exceptions instead of E_ERROR. Now, about asynchronous operations, PHP developers are also often Javascript developers, may it be front end or back end on Node. Lots of them are used to asynchronous calls, others will simply learn to be used to it or continue to use the current synchronous functionalities and SAPIs, I see this as an opt-in. Lots of PHP developers don't know what is a process or a thread and doesn't feel the need to dig the subject and I'm perfectly ok with that, each project finds his own needs and solutions. That said, then why should concerned developers suffer from missing functionalities? I used to be a proponent of integrating things like this directly into the core of PHP. However I no longer consider this to be a good idea. Why? Because all of the functionality needed to implement these things yourself is available in extensions *right now.* I've personally worked on a closed-source userland non-blocking HTTP+websocket server over the last couple of years that clears 80,000 requests per second with 10,000 simultaneous clients running PHP7 on a single box with an i2600K cpu. Is this server running with php-uv? The issue here is that there is no simple and uniform way to implement it. Agree with me or not, it is clearly reserved to a small part of seasoned PHP developers, used to concurrent programming, extension writing/compilation and asynchronous development. It is a border-line way of developing with PHP, not portable at all as long as php-uv isn't available anywhere but on your own dedicated server (if your SysOP even accepts to install a considered self-maintained and possibly vulnerable extension). Instead of massively changing the fundamental nature of the PHP web SAPI I believe we should focus on improving PHP as a language and not a web framework. By doing so we make it increasingly possible to implement things like this directly in userland with good performance. This can be accomplished right now by simply focusing on extension development (like php-uv which you mentioned and I've contributed to myself). I'm just bringing some ideas here, as long as I'm not a php-src developer. I know some notions but I don't have the distance required to find -by myself- the best solutions. Yes php-uv is a great tool, but still incomplete (and IMO missing an OOP API). Would I personally prefer to re-implement everything in PHP on top of libuv and bake non-blocking and threaded concurrency directly into the language with async functions and promises? Absolutely. But you're talking about a massive amount of work here. In standard internet parlance ... ain't no one got time for that. I can't tell if the existing stream API can integrate libuv I/O handling, especially async ones. I figured out that it was nearly impossible to integrate php-uv in an userland streamWrapper. Now, that said and to come back to the main subject, HTTP/2 is coming *now* in production on large scale websites and will be present in a large amount of web traffic in the next couple of years. PHP can't afford to miss the boat or to force each developer reimplement his own protocol layer. 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
Re: [PHP-DEV] Naming of 'weak' type hints
On Tuesday, 31 March 2015, Zeev Suraski z...@zend.com wrote: All, One thing that I think we should change is how we refer to the ‘weak’ type hints. The word ‘weak’ has a negative ring to it, and considering this is how the language behaves across the board it’s a pretty bad name for this feature. Personally I think we should go for ‘dynamic’ when we document it, as this is the common way to refer to this behavior (dynamic languages). We could also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’, although I think we can easily do without introducing a new word into the vocabulary here. Thoughts? Zeev Coercive? -- Regards, Terry Cullen Freelance Senior PHP Programmer/Web Developer -- Phone 1300-955-838 +61-1300-955-838Mobile 04-3836-8032 +61-4-3836-8032 Email te...@terrycullen.com.auWeb http://www.terrycullen.com.au/G-Talk te...@terrycullen.com.au13 Jarrott St, ChelmerTerah Pty Ltd | ACN 135 365 552 http://www.terrycullen.com.au/[image: Terah Pty Ltd logo] http://www.terrycullen.com.au/
Re: [PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
Hi, On 31.03.2015 17:40, Daniel Lowrey wrote: On Tue, Mar 31, 2015 at 10:11 AM Grégory Planchat greg...@luni.fr wrote: Le 31/03/2015 15:56, Daniel Lowrey a écrit : HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently exists. The protocol impacts the actual HTTP server and has nothing to do with the SAPI runtime which is simply handed information about the HTTP request once the server parses it. The protocol used to communicate those details between the client and the HTTP server does not concern the web SAPI. There is no need for any sort of support for h2 in PHP; it's the web server's concern. Apache and nginx will add support for h2 and PHP will continue working as it always has. That said, the php web SAPI derives exceedingly little benefit from the advent of HTTP/2.0. h2 is designed to allow multiplexing of many requests over the same TCP connection but the PHP web SAPI still has the same bottleneck it had before h2: one thread/process per request. As for websockets, you *can* do that using the web SAPI right now if you wished but this would be inadvisable because long-lived connections will quickly fill the bottleneck in every PHP web application (concurrent threads/processes for each request). Instead, the appropriate solution for websockets would be to implement a socket server directly in the CLI that speaks the websocket protocol. Would it be useful to have raw incremental parsing functionality for HTTP/1.1, HTTP/1.2 and websocket protocols available in userland? Sure, but this falls more in the realm of an extension than anything else as few people are implementing full-blown http and websocket servers in the CLI right now. Hi Daniel, Your message is focusing on the solution I can find today in the wild, not about the need mys previous message was about, namely multiplexing and message push. Anyway I'm aware of this and I understand your point, but why should'nt we be able, natively, to exploit HTTP/2 enhancements, particurlarly resources multiplexing and data push? Why woud we restrain to exploit 20 years old protocol features, deliberately omitting new ones that are already implemented on other platforms? Grégory You're right -- I was addressing the status quo. The issue here is this: the web SAPI is historically the most stable thing about PHP. Supporting things like message push and multiplexing would require a fundamental change in what the web SAPI is. You would have to junk the entire model and create something completely new. It wouldn't be PHP anymore because you couldn't use the thread/process per-request model; users could no longer rely on the ease and simplicity of every function call being a simple synchronous operation. this ain't exactly true. Currently in MT environment the task of data separation is pushed to the TSRM by using TLS. Now, if TSRM is reimplemented in a fashion that the data is not stored by using TLS but other mechanism and cooperative multitasking is not something that can't be done. The truth is that userland is isolated from the process data space so for it it won't make a difference. It's just that using threads for separation is the easiest thing (after process per script). The good thing is that TSRM is an abstraction for its clients. This kind of major paradigm shift is something that couldn't remotely be considered for PHP7. Even if it were possible you have to consider the web SAPI's target demographic. This demographic knows nothing about non-blocking IO and multitasking. I used to be a proponent of integrating things like this directly into the core of PHP. However I no longer consider this to be a good idea. Why? Because all of the functionality needed to implement these things yourself is available in extensions *right now.* I've personally worked on a closed-source userland non-blocking HTTP+websocket server over the last couple of years that clears 80,000 requests per second with 10,000 simultaneous clients running PHP7 on a single box with an i2600K cpu. Instead of massively changing the fundamental nature of the PHP web SAPI I believe we should focus on improving PHP as a language and not a web framework. By doing so we make it increasingly possible to implement things like this directly in userland with good performance. This can be accomplished right now by simply focusing on extension development (like php-uv which you mentioned and I've contributed to myself). Would I personally prefer to re-implement everything in PHP on top of libuv and bake non-blocking and threaded concurrency directly into the language with async functions and promises? Absolutely. But you're talking about a massive amount of work here. In standard internet parlance ... ain't no one got time for that. Best, Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] password_hash() deprecate salt option - thoughts?
All, Ever since we introduced password_hash() in 5.5, I've been watching its usage as much as possible. I've setup google alerts and such, as well as auditing implementations I've found on github to try to understand how it's used. One thing has become abundantly clear to me: the salt option is dangerous. I've yet to see a single usage of the salt option that has been even decent. Every usage ranges from bad (passing mt_rand() output) to dangerous (static strings) to insane (passing the password as its own salt). I've come to the conclusion that I don't think we should allow users to specify the salt. The crypt() API still exists if users have a need to generate their own salt. Having it in the simplified API is simply adding a risk factor without any significant justification. So I'd like to hear your thoughts about raising E_DEPRECATED when the salt option is specified in 7.0, with ultimately removing the option in a later version. Additionally, I know this is after the RFC freeze deadline, so if you want to postpone the deprecation to 7.1, that's fine. I just think it's worth discussion (and if there's consensus to put it in 7.0, then great). Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: password_hash() deprecate salt option - thoughts?
I'd vote yes on this one, if it were an RFC. Please expedite this deprecation for 7.0. Can we also deprecate MCRYPT_RAND? I opened an RFC for that a long time ago and just remembered it.
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! The problem is always a definition question, a very subjective question. Fortunately, we can discuss it, we're not limited to blindly following predefined set of rules. I do not really buy the I am stuck with x.y as one has the same problem already. And he has barely a 2 years window to add them. No, right now you can add small enhancements to 5.5/5.6 and get it in production in terms of months, not several years. About 7, yes, that's our only next release. We rejected any 5.7, so we have to live with it. This has nothing to do with 5.7, 5.7 was proposed as BC break fodder, not as release vehicle for adding enhancements. In any case, even if we had 5.7, one it's released you can't add anything to it anymore, so you're back to square one. In any case, you have to wait years for any small enhancement to become available, unless you happen to be extremely lucky to propose it just before the release of the next major. Now, about the BC breaks, I do not see that much BC breaks for modern apps and even WP or D7 work quite well. Let focus on that instead of You know PHP world is much bigger than WP or D7, right? I've seen people still running 5.2 in production and reluctant to go forward. Look at the adoption figures. 5.6 is barely 1% and you propose add features into 7.1. Who'll use them - 0.0001%? People care about WP if they run WP - but most of them run their own apps. Or an assembly of apps, all different. starting to using 5.6 as a solution of our frustration not being able to move to 7, that would be terrible to have new features every patch release. Let do not do that. It would be excellent to add new features each release. Let's do that. You see, I can argue like you - blanket statement without any substantiation. Can you also substantiate your position? I just did and you rejected it with a blanket statement no, it's terrible. No, it's not, and the facts - including very low adoption of current versions - support it. Until we get better adoption, I don't see how it makes any sense to effectively ban any enhancements for 99.99% of PHP users. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?
On Tue, Mar 31, 2015 at 8:49 PM, Anthony Ferrara ircmax...@gmail.com wrote: All, Ever since we introduced password_hash() in 5.5, I've been watching its usage as much as possible. I've setup google alerts and such, as well as auditing implementations I've found on github to try to understand how it's used. One thing has become abundantly clear to me: the salt option is dangerous. I've yet to see a single usage of the salt option that has been even decent. Every usage ranges from bad (passing mt_rand() output) to dangerous (static strings) to insane (passing the password as its own salt). I've come to the conclusion that I don't think we should allow users to specify the salt. The crypt() API still exists if users have a need to generate their own salt. Having it in the simplified API is simply adding a risk factor without any significant justification. So I'd like to hear your thoughts about raising E_DEPRECATED when the salt option is specified in 7.0, with ultimately removing the option in a later version. Additionally, I know this is after the RFC freeze deadline, so if you want to postpone the deprecation to 7.1, that's fine. I just think it's worth discussion (and if there's consensus to put it in 7.0, then great). Agree with deprecating the custom salt option and also okay with doing it in 7.0. Nikita
Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?
I think deprecating it is a good idea, and looking at the documentation it does mention that not providing it is the intended option; so it isn't a complete surprise for it to become deprecated. On 31 March 2015 at 19:49, Anthony Ferrara ircmax...@gmail.com wrote: All, Ever since we introduced password_hash() in 5.5, I've been watching its usage as much as possible. I've setup google alerts and such, as well as auditing implementations I've found on github to try to understand how it's used. One thing has become abundantly clear to me: the salt option is dangerous. I've yet to see a single usage of the salt option that has been even decent. Every usage ranges from bad (passing mt_rand() output) to dangerous (static strings) to insane (passing the password as its own salt). I've come to the conclusion that I don't think we should allow users to specify the salt. The crypt() API still exists if users have a need to generate their own salt. Having it in the simplified API is simply adding a risk factor without any significant justification. So I'd like to hear your thoughts about raising E_DEPRECATED when the salt option is specified in 7.0, with ultimately removing the option in a later version. Additionally, I know this is after the RFC freeze deadline, so if you want to postpone the deprecation to 7.1, that's fine. I just think it's worth discussion (and if there's consensus to put it in 7.0, then great). Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?
Nicolas Oelgart wrote: On 31 Mar 2015, at 20:49, Anthony Ferrara ircmax...@gmail.com wrote: So I'd like to hear your thoughts about raising E_DEPRECATED when the salt option is specified in 7.0, with ultimately removing the option in a later version. +1 I'd even go as far as adding a big red warning about custom salts to the manual page. FWIW, there is already the following note: | Caution It is strongly recommended that you do not generate your own | salt for this function. It will create a secure salt automatically | for you if you do not specify one. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
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
Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?
On 31 Mar 2015, at 21:32, Christoph Becker cmbecke...@gmx.de wrote: Nicolas Oelgart wrote: On 31 Mar 2015, at 20:49, Anthony Ferrara ircmax...@gmail.com wrote: So I'd like to hear your thoughts about raising E_DEPRECATED when the salt option is specified in 7.0, with ultimately removing the option in a later version. +1 I'd even go as far as adding a big red warning about custom salts to the manual page. FWIW, there is already the following note: | Caution It is strongly recommended that you do not generate your own | salt for this function. It will create a secure salt automatically | for you if you do not specify one. -- Christoph M. Becker Yeah, I’m aware. But I don’t think it’s enough. I’d suggest moving it further to the top, and making it red. As Anthony’s research shows, the current note is not enough. People are still doing it wrong. — Nico -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
On 31.03.2015 18:26, Rowan Collins wrote: Andrey Hristov wrote on 31/03/2015 16:02: Currently in MT environment the task of data separation is pushed to the TSRM by using TLS. Now, if TSRM is reimplemented in a fashion that the data is not stored by using TLS but other mechanism and cooperative multitasking is not something that can't be done. The truth is that userland is isolated from the process data space so for it it won't make a difference. It's just that using threads for separation is the easiest thing (after process per script). The good thing is that TSRM is an abstraction for its clients. Isn't the point that to get a real advantage from these technologies, the *userland* needs to be aware of threads / events? That's what requires a fundamental rethink of the language. No, actually it doesn't need threads. There is no need to introduce threads. Threads are for coarsely grained tasks. It is overkill to start and finish threads in this environment. It is not overkill to have pool of threads that can execute simple tasks. PHP doesn't have this problem - the need for threads. PHP's problem are all the blocking APIs, including the ones I have worked on and created myself. PHP needs non-blockable APIs + a notion of coroutines + promises. How the coroutines are scheduled is not important (whether in the same thread, on thread pool, even in another process). Directly sharing data should not be possible, only serialized input/output. TSRM/TLS allows you to drop from one-process-per-request to one-thread-per-request, but it doesn't save you the expense of repeatedly building up and tearing down an execution environment. So, if Zend can be optimized to quickly clean the execution environment, and easily switch between them, we can have a giant leap towards concurrent non-blockable PHP. The idea is simple - the Zend environment should be some structure, and TSRM needs implementation not using TLS, in this case. The MySQL Server used to bind a connection to a thread but since years these are decoupled and with the right plugin you can have 100 threads serving many times more connections because thread switching is an expensive task. This ain't rocket science. Regards, Best, Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?
On Tue, Mar 31, 2015 at 7:49 PM, Anthony Ferrara ircmax...@gmail.com wrote: All, Ever since we introduced password_hash() in 5.5, I've been watching its usage as much as possible. I've setup google alerts and such, as well as auditing implementations I've found on github to try to understand how it's used. One thing has become abundantly clear to me: the salt option is dangerous. I've yet to see a single usage of the salt option that has been even decent. Every usage ranges from bad (passing mt_rand() output) to dangerous (static strings) to insane (passing the password as its own salt). I've come to the conclusion that I don't think we should allow users to specify the salt. The crypt() API still exists if users have a need to generate their own salt. Having it in the simplified API is simply adding a risk factor without any significant justification. So I'd like to hear your thoughts about raising E_DEPRECATED when the salt option is specified in 7.0, with ultimately removing the option in a later version. Additionally, I know this is after the RFC freeze deadline, so if you want to postpone the deprecation to 7.1, that's fine. I just think it's worth discussion (and if there's consensus to put it in 7.0, then great). Thanks, Anthony No objections here. You're going with your gut on this and it seems like a good call. We did make a freeze and although I'd like it in 7.0 we should probably stick to our process here and put it in 7.1. To be fair, there's always a quick *.1 release anyway once we find real-world bugs that need patching quickly ;-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev smalys...@gmail.com wrote: This is a straw man as far as the points I made are concerned. I'm talking about the risk of switching from 5.5 to 5.6, which is pretty low. Switching to 5.6 would be useless since what is being propose it to ban any enhancements up to 7.1. Proposed by whom? The only mentions of 7.1 I've spotted have been from you, which is why I called it a straw man. So, rather than arguing round in circles, here's what I would propose: - Up until the first release candidate of x.y.0, small features can be added to both the most recent live branch and the new branch being prepared for release (so, right now, 5.6.x and 7.0-pre; next summer, 7.0.x and 7.1-pre). - Once a new x.y.0 release is ready, x.y-1.z releases should receive bug fixes only. Thus 5.5.x should not be receiving features. - As an exception to the above, when releasing x.0.0, the previous branch may continue receiving small features, until it reaches the end of its active support phase. In other words, keep backporting things to 5.6.x after 7.0.0 is released, since adoption of the latter is likely to be slow. By the time 7.1.0 comes around, active support for 5.6 will have ended anyway, unless we make some other exception to the normal process. This is very much a compromise between the SemVer ideal of a patch release, and the practical implications of a yearly release cycle. The aim is to make it obvious to users what they'll get in return for upgrading, and to smoothly transition a branch from cutting edge to stable with bug fixes, then to security only and end of life. What do people think? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Sorry for the double reply, but I wanted to pick up on one particular point. On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev smalys...@gmail.com wrote: Hi! That's not quite how it works; the distro package maintainers maintain a sort of forked version of upstream code, combining a well-tested upstream release with a set of patches, many of which will be backported fixes from newer releases. So the current package in Ubuntu 14.04 LTS [see http://packages.ubuntu.com/trusty/php5] is 5.5.9+dfsg-1ubuntu4.7, and the Ubuntu Changelog shows 12 releases, mostly for security patches, which is nearly as many as there have been upstream releases. I think this is all wrong, because I don't see how they can do better testing with random set of patches than with real release version, but that's beside the point. It may actually be the loose upstream definition of stability that motivates packagers to do this - they don't want to include new features, with their own potential bugs. It seems to be common practice, at least in the Debian ecosystem, so evidently they think it works out for the best. Note that they also continue to maintain their patches *after* the corresponding release branch is EOL on php.net. For instance, here is the ongoing changelog for Ubuntu 12.04LTS's package, based on PHP 5.3: http://changelogs.ubuntu.com/changelogs/pool/main/p/php5/php5_5.3.10-1ubuntu3.17/changelog If somebody were to go out of their way to install a non-default package, it's unlikely to be to include a minor change of the type we're discussing here. More likely, they would move to a newer stable branch, since the risk is only slightly higher (thanks to our minor releases being more truly minor since 5.4), and the reward much greater. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes
hi Nikita, I don't care about this a lot. I reworked this patch just because it missed few details, and then found and fixed mistake in ext/intl. If you think TypeException is better (I think this makes sense), please implement it on top and commit. Thanks. Dmitry. On Tue, Mar 31, 2015 at 11:07 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Mar 30, 2015 at 6:06 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Dan, The updated patch is at https://github.com/php/php-src/pull/1205 The main difference is in ext/intl. If you don't see any problems I can commit it. I didn't think about the classes you missed. Thanks. Dmitry. I'm wondering, if we implement throwing zpp by using EH_THROW mode, which relies on converting warnings to exceptions, does that mean that the same code using strict_types=1 mode will start throwing TypeException instead of whatever exception type is passed to replace_error_handling? If so, that would be pretty weird. Maybe we should just always throw TypeException for this? Could also add a zpp flag for doing that as all the code for throwing TypeExceptions is already present, we just need to trigger it. Nikita
[PHP-DEV] HTTP/2 and Websocket support in 7.x versions
Hi, I've been reading about PHP7 RFC ans I did not see anything about HTTP/2 support in any threads on internals nor the wiki. I'm aware that HTTP is the responsibility of the underlying web server, but there are new *important* features to consider. I know the feature list for PHP7 is now frozen, but this is an important feature for upcomimg 7.x versions, as long as this *IS* the future of the web. 1. HTTP/2 multiplexing HTTP/2 comes with document and resources multiplexing on one unique TCP connection stream [1]. Support is coming quickly in web servers[2][3], by late 2015 Apache and Nginx should support natively or via a module HTTP/2, just at the time PHP7 should be released. To set the context, currently with HTTP/1.x the images, css, js, and other resources are just referenced in the HTML and then loaded by the HTTP client once the HTML has been requested and loaded, but there is no explicit link between documents on the server side. As a result, each resource consumes one TCP stream. Some optimisations exists like Connection: keep-alive, but it just save some TCP handshakes, the client still waits the loading of the HTML *BEFORE* requesting the js/css/images/resources. There is also a data:// protocol for small size resources, but it is not practical at all and suffers from partial support in the browsers. How would one specify which resources should be sent *WITH* the generated HTML? Is there anything in the FastCGI protocol to support these sort of features (via header or metadata or something else)? Alongside, is there something equivalent that would be possible to do in the PHP/Apache module? 2. HTTP/2 response push and WebSocket 2.1 State of the art and Native HTTP server Another important feature is the push feature. How would it be possible to implement in further versions of PHP, without having to reimplement the HTTP server like the ReactPHP[4] project? Considering the fact that there is no enterprise-ready and performant application loop manager integrated natively in PHP core (using either forked or asynchronous), like Node.js's libuv, these solutions are destined for very small APIs and applications. Since PHP 5.3, there is the -S option for starting an internal HTTP server. Isn't there any plans to map this server to an userland API? This server has in fact all the logic needed by applications like ReactPHP[4], which has to reimplement it(!). Shouldn't there any other solution planned in PHP 7.x? 2.2. Solution 1: Implementing server from the ground with OS abstraction and application loops Solution of implmeenting from the ground the HTTP server is what ReactPHP did and is for now the most used solution. Some would say that these issues should be kept in the userland, but please, read to the end. Furthermore, integrating in the core an OS-abtracted API for process management and asynchronous I/O could be a big performance jump, with an extension being to ext/pcntl what PDO has been to ext/mysqli in PHP 5.x. As I wrote previously, Node.js has libuv which started as an abstraction layer for Node's to libev and Windows and became a full featured OS abstraction layer for process and I/O management. Shuhei Tanuma (with the help of other contributors) has implmented an experimental binding named ext/uv[5] that could be a start to implment a similar feature set in PHP. I used it for a while in a personal and experimental project, it is functional despite of some (very rare) crashes (and IMO a missing OOP-style API, which is more a personal taste than an issue). In the same vein, we have pcntl[6], eio[7], ev[8], libevent[9], pthreads[10], working in their own way but no uniform API, some use functional style, others are OOP style and there is maybe interoperability issues and feature overlapping (I did not test all of them in a single project). Some even aren't integrated in the standard release and are availiable on PECL only. As long as all these features are currently in extensions or in a SAPI, why wouldn't it be integrated in an unique extension/API? The changes in the SI architecture between PHP and the web server would be to transform the CGI interconnections to classical HTTP proxy connections. 2.3. Solution 2 : Define some other way, extending the SAPIs and/or the CGI API I can't tell if it is even possible to implment this, as long as the current architecture depends on the underlying layer sollicitations (HTTP server/CLI/ect...). Currently, PHP itself doesn't decide to send some data to the client such as push features, it must wait for its caller to be invoked, or manage the full application stack. Maybe it is all the request lifecycle that has to be rethought from the ground as an application of 2015 is radically different from a 1995 application (or even from 2005). 3. Conclusion Maybe there are other solutions. HTTP/2 has been released and a massive migration is about to come in
RE: [PHP-DEV] Naming of 'weak' type hints
De : Zeev Suraski [mailto:z...@zend.com] One thing that I think we should change is how we refer to the ‘weak’ type hints. The word ‘weak’ has a negative ring to it, and considering this is how the language behaves across the board it’s a pretty bad name for this feature. What about 'loose' vs 'strict' type hinting ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
hi, ps: please keep the xyz wrote, makes harder to read your replies without it On Wed, Apr 1, 2015 at 2:57 AM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! The problem is always a definition question, a very subjective question. Fortunately, we can discuss it, we're not limited to blindly following predefined set of rules. That one is rather easy to follow and disallow any kind of bully pushes. I do not really buy the I am stuck with x.y as one has the same problem already. And he has barely a 2 years window to add them. No, right now you can add small enhancements to 5.5/5.6 and get it in production in terms of months, not several years. Which years are you referring to? Let put things back in perspective: Since we introduced the release process RFC, more or less followed correctly but lately, distributions adopt latest PHP releases much faster. See Fedora, Debian and Ubuntu for example. I have discussed it with a couple of maintainers (of these distros) and they all like this new process and would like even more strictness when it comes to new features. Why? Because it makes their work easier, be testing, validating a new release for a LTS, etc. So what you are saying is that now we are on track to actually improve new releases adoption we should not make it even easier? Or go backward by cluttering stable releases with new features? Sorry, I cannot agree here. About 7, yes, that's our only next release. We rejected any 5.7, so we have to live with it. This has nothing to do with 5.7, 5.7 was proposed as BC break fodder, not as release vehicle for adding enhancements. In any case, even if we had 5.7, one it's released you can't add anything to it anymore, so you're back to square one. In any case, you have to wait years for any small enhancement to become available, unless you happen to be extremely lucky to propose it just before the release of the next major. You brought the even longer with 7 argument, 5.7 could have prevented you for having to wait years to get one minor features or another. That's all. Now, about the BC breaks, I do not see that much BC breaks for modern apps and even WP or D7 work quite well. Let focus on that instead of You know PHP world is much bigger than WP or D7, right? No comment. Pointless troll. I am the one keep saying that I do not like us using only WP to validate changes. I've seen people still running 5.2 in production and reluctant to go forward. Look at the adoption figures. 5.6 is barely 1% and you propose add features into 7.1. Who'll use them - 0.0001%? People care about WP if they run WP - but most of them run their own apps. Or an assembly of apps, all different. Chicken-egg problem, wait until people actually moves away from old Debian/RHEL and adopt recent ones. This is what I am saying since long and in the previous paragraph. Please at least try to see that. starting to using 5.6 as a solution of our frustration not being able to move to 7, that would be terrible to have new features every patch release. Let do not do that. It would be excellent to add new features each release. Let's do that. You see, I can argue like you - blanket statement without any substantiation. Can you also substantiate your position? I just did and you rejected it with a blanket statement no, it's terrible. No, it's not, and the facts - including very low adoption of current versions - support it. Until we get better adoption, I don't see how it makes any sense to effectively ban any enhancements for 99.99% of PHP users. A blanket statement? We discussed that many times already, my stance did not change a single yota since then. I repeated it here once again to make it clear, and for the record. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
On 31 March 2015 21:23:56 GMT+01:00, Andrey Hristov p...@hristov.com wrote: So, if Zend can be optimized to quickly clean the execution environment, and easily switch between them, we can have a giant leap towards concurrent non-blockable PHP. The idea is simple - the Zend environment should be some structure, and TSRM needs implementation not using TLS, in this case. The MySQL Server used to bind a connection to a thread but since years these are decoupled and with the right plugin you can have 100 threads serving many times more connections because thread switching is an expensive task. This ain't rocket science. You make it sound so simple, but the fact that an environment is set up and torn down for each request is fundamental to the whole language, not just a detail of the engine. If all you're doing is making that setup and teardown quicker, I don't see how you're getting any closer to asynchronous code. FPM could do all sorts of magic with its memory management, but it wouldn't help someone write a WebSocket server. Maybe I'm missing something, but I can't picture how you'd have a meaningfully event-based SAPI that looked just like a single-request one to the user. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
On 1.04.2015 00:31, Rowan Collins wrote: On 31 March 2015 21:23:56 GMT+01:00, Andrey Hristov p...@hristov.com wrote: So, if Zend can be optimized to quickly clean the execution environment, and easily switch between them, we can have a giant leap towards concurrent non-blockable PHP. The idea is simple - the Zend environment should be some structure, and TSRM needs implementation not using TLS, in this case. The MySQL Server used to bind a connection to a thread but since years these are decoupled and with the right plugin you can have 100 threads serving many times more connections because thread switching is an expensive task. This ain't rocket science. You make it sound so simple, but the fact that an environment is set up and torn down for each request is fundamental to the whole language, not just a detail of the engine. If all you're doing is making that setup and teardown quicker, I don't see how you're getting any closer to asynchronous code. FPM could do all sorts of magic with its memory management, but it wouldn't help someone write a WebSocket server. being able to serve more than 1 request in a thread by not using TLS allows you to lower the number of threads used, significantly. On top of that by adding coroutines which run on a thread pool with fast setup and teardown give you the notion of parallel execution and because data is exchanged with the coroutines only in serialized way, not by sharing it, a bunch of problems related to concurrency won't happen. Add promises to this soup together with non-blocking APIs (this won't happen overnight) and everything fits. Maybe I'm missing something, but I can't picture how you'd have a meaningfully event-based SAPI that looked just like a single-request one to the user. I don't think that the SAPI needs to change. The SAPI doesn't mandate processes, threads or whatever else primitives. It's a way to (de)initialize module/request. Regards, Best, Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?
No objections here either. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Backwards compatibility with set_exception_handler callback and type hints
So testing out PHP 7 I triggered an \EngineException() in Drupal 8. For various reasons that don't really matter here Drupal uses set_exception_handler() to provide its own exception handler. What is important is that the methods used by that handler type hint \Exception for their arguments. The immediately fatals. By design, \EngineException does not extend \Exception so code doesn't accidentally catch this special type of exception. Unfortunately they still always make their way into this exception handler. Unfortunately this means we have to remove the type hinting to support forward compatibility which is a bit akward and unfortunate. I don't know if this is all acceptable and/or by design but it is awkward so I wanted to bring it to the list to discuss. Simplified test case. Sorry for not putting it on 3v4l but its currently unreachable. https://gist.github.com/neclimdul/ab29ddb223cfc197e635
Re: [PHP-DEV] HTTP/2 and Websocket support in 7.x versions
On 3/31/15 8:31 AM, Grégory Planchat wrote: Hi, I've been reading about PHP7 RFC ans I did not see anything about HTTP/2 support in any threads on internals nor the wiki. I'm aware that HTTP is the responsibility of the underlying web server, but there are new *important* features to consider. I know the feature list for PHP7 is now frozen, but this is an important feature for upcomimg 7.x versions, as long as this *IS* the future of the web. 1. HTTP/2 multiplexing HTTP/2 comes with document and resources multiplexing on one unique TCP connection stream [1]. Support is coming quickly in web servers[2][3], by late 2015 Apache and Nginx should support natively or via a module HTTP/2, just at the time PHP7 should be released. To set the context, currently with HTTP/1.x the images, css, js, and other resources are just referenced in the HTML and then loaded by the HTTP client once the HTML has been requested and loaded, but there is no explicit link between documents on the server side. As a result, each resource consumes one TCP stream. Some optimisations exists like Connection: keep-alive, but it just save some TCP handshakes, the client still waits the loading of the HTML *BEFORE* requesting the js/css/images/resources. There is also a data:// protocol for small size resources, but it is not practical at all and suffers from partial support in the browsers. How would one specify which resources should be sent *WITH* the generated HTML? Is there anything in the FastCGI protocol to support these sort of features (via header or metadata or something else)? Alongside, is there something equivalent that would be possible to do in the PHP/Apache module? We discussed this briefly in the FIG regarding PSR-7. It looks like H2O and nginx have both adopted a standard of using a Link header with rel preload to indicate HTTP2, push this along with it if you can. So if your PHP code just sends a bunch of extra Link-preload headers, the web server should figure it out and do the work for you if it can. (And if it doesn't, and the browser ignores it too, ignored headers are ignored.) So that part at least is already possible. Push messages and WebSockets are an interesting problem space, though, and I agree some careful thinking is needed there. It's related to, but distinct from, the questions around native async/non-blocking PHP (which I also fully support in concept). --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes
On Mon, Mar 30, 2015 at 6:06 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Dan, The updated patch is at https://github.com/php/php-src/pull/1205 The main difference is in ext/intl. If you don't see any problems I can commit it. I didn't think about the classes you missed. Thanks. Dmitry. I'm wondering, if we implement throwing zpp by using EH_THROW mode, which relies on converting warnings to exceptions, does that mean that the same code using strict_types=1 mode will start throwing TypeException instead of whatever exception type is passed to replace_error_handling? If so, that would be pretty weird. Maybe we should just always throw TypeException for this? Could also add a zpp flag for doing that as all the code for throwing TypeExceptions is already present, we just need to trigger it. Nikita
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! That's not quite how it works; the distro package maintainers maintain a sort of forked version of upstream code, combining a well-tested upstream release with a set of patches, many of which will be backported fixes from newer releases. So the current package in Ubuntu 14.04 LTS [see http://packages.ubuntu.com/trusty/php5] is 5.5.9+dfsg-1ubuntu4.7, and the Ubuntu Changelog shows 12 releases, mostly for security patches, which is nearly as many as there have been upstream releases. I think this is all wrong, because I don't see how they can do better testing with random set of patches than with real release version, but that's beside the point. The point is it's very easy to make a deployable package from php.net source pack, but it's much harder to move an organization to different version that may cause BC breaks and other disruption. It's both technical and organizational - try to propose moving software from version 5.5.23 to 5.5.24 and from 5.x to 7.x and ask anybody which is riskier. Almost universally you'd be told the latter is much riskier. This is a straw man as far as the points I made are concerned. I'm talking about the risk of switching from 5.5 to 5.6, which is pretty low. Switching to 5.6 would be useless since what is being propose it to ban any enhancements up to 7.1. Well, you could fork the JSON extension, I guess. But yes, not all options are available in all cases. For most enhancements, no options but wait for a couple of years are available unless you want to maintain a full-blown php fork. That's completely the opposite of what I said. I said I *do* think adding small features to 5.6 may be justified, since 7.0 will be a more painful upgrade. Then we agree. But the proposal here was to ban all enhancements in released versions. This is just wrong, and I am glad you support it. The type of backporting I'm questioning is adding features to 5.5.x, when we have 5.6.x released, and 7.0.x in preparation. And, *after* the 7.1.0 release towards the end of next year, I would not expect features to be backported to 7.0. Depends on features. In principle I'd be fine with enhancement going only into 5.6, but given its abysmal adoption so far, practically I can see the case for some stuff in 5.5 too. But I recognize it's chicken and egg problem, so if we can reach consensus on 5.6, I can live with that. No, indeed. There, the cost is only on the developer having to ensure that they don't deploy code relying on the new option to a server one patch version too old. This is a regular version requirement concern which ops should be well familiar with and be able to handle. prefixes like error_*, file_*, etc. So, for simplicity, you might as well treat the global namespace as out of bounds. In my code, I'd be wary of putting non-prefixed functions into global namespace. PHP versions is only one reason - if two libraries have error_report() function, they never can be used together, not a good thing. I'd rather call it my_library_error_report() if for some reason I can't namespace it properly. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HTTP/2 and Websocket support in 7.x versions
Le 31/03/2015 23:45, Larry Garfield a écrit : On 3/31/15 8:31 AM, Grégory Planchat wrote: Hi, I've been reading about PHP7 RFC ans I did not see anything about HTTP/2 support in any threads on internals nor the wiki. I'm aware that HTTP is the responsibility of the underlying web server, but there are new *important* features to consider. I know the feature list for PHP7 is now frozen, but this is an important feature for upcomimg 7.x versions, as long as this *IS* the future of the web. 1. HTTP/2 multiplexing HTTP/2 comes with document and resources multiplexing on one unique TCP connection stream [1]. Support is coming quickly in web servers[2][3], by late 2015 Apache and Nginx should support natively or via a module HTTP/2, just at the time PHP7 should be released. To set the context, currently with HTTP/1.x the images, css, js, and other resources are just referenced in the HTML and then loaded by the HTTP client once the HTML has been requested and loaded, but there is no explicit link between documents on the server side. As a result, each resource consumes one TCP stream. Some optimisations exists like Connection: keep-alive, but it just save some TCP handshakes, the client still waits the loading of the HTML *BEFORE* requesting the js/css/images/resources. There is also a data:// protocol for small size resources, but it is not practical at all and suffers from partial support in the browsers. How would one specify which resources should be sent *WITH* the generated HTML? Is there anything in the FastCGI protocol to support these sort of features (via header or metadata or something else)? Alongside, is there something equivalent that would be possible to do in the PHP/Apache module? We discussed this briefly in the FIG regarding PSR-7. It looks like H2O and nginx have both adopted a standard of using a Link header with rel preload to indicate HTTP2, push this along with it if you can. So if your PHP code just sends a bunch of extra Link-preload headers, the web server should figure it out and do the work for you if it can. (And if it doesn't, and the browser ignores it too, ignored headers are ignored.) So that part at least is already possible. Push messages and WebSockets are an interesting problem space, though, and I agree some careful thinking is needed there. It's related to, but distinct from, the questions around native async/non-blocking PHP (which I also fully support in concept). --Larry Garfield HI Larry, I was not aware of this header, thanks for the infomation, at least it solves easily one of my points. Now, about WebSockets and HTTP/2 messages push, yes it needs to be thinked carefully. At this stage I'm just fixing some ideas, you can eventually tell me if you agree with them or not. * Maybe some feedback could be taken from ReactPHP development team about the needs of an (exsisting) asynchronous application in the PHP world. * Asynchronous I/O is mandatory for an userland daemon as seen in ReactPHP, but there could be some other pathes such as a specific SAPI running worker threads (in fact, the networking tasks would be kept out of userland scope by the SAPI itself, just like what the CLI SAPI with -S option does for classical HTTP requests, each worker would be a callable, or even better: a generator exploiting yield's bidirectional messaging) * PSR-7, when published, could be an interesting starting point about message push, to think it deeper if the async I/O option is chosen * WebSocket and WAMP protocols have also to be implemented by this SAPI if this option is chosen. As a consequence further protocols updates will have to be handled by @internals team as long as userland code does not handle it * During PHP7 discussions, some mentioned Zephir to build extensions. Sara Golemon told me on Twitter she was working on a common API for HHVM and php-src. Maybe this set of features could be implemented with these emerging solutions Grégory Planchat -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HTTP/2 and Websocket support in 7.x versions
hi, On Tue, Mar 31, 2015 at 8:31 PM, Grégory Planchat greg...@luni.fr wrote: Hi, I've been reading about PHP7 RFC ans I did not see anything about HTTP/2 support in any threads on internals nor the wiki. I'm aware that HTTP is the responsibility of the underlying web server, but there are new *important* features to consider. I know the feature list for PHP7 is now frozen, but this is an important feature for upcomimg 7.x versions, as long as this *IS* the future of the web. 1. HTTP/2 multiplexing HTTP/2 comes with document and resources multiplexing on one unique TCP connection stream [1]. Support is coming quickly in web servers[2][3], by late 2015 Apache and Nginx should support natively or via a module HTTP/2, just at the time PHP7 should be released. To set the context, currently with HTTP/1.x the images, css, js, and other resources are just referenced in the HTML and then loaded by the HTTP client once the HTML has been requested and loaded, but there is no explicit link between documents on the server side. As a result, each resource consumes one TCP stream. Some optimisations exists like Connection: keep-alive, but it just save some TCP handshakes, the client still waits the loading of the HTML *BEFORE* requesting the js/css/images/resources. There is also a data:// protocol for small size resources, but it is not practical at all and suffers from partial support in the browsers. How would one specify which resources should be sent *WITH* the generated HTML? Is there anything in the FastCGI protocol to support these sort of features (via header or metadata or something else)? Alongside, is there something equivalent that would be possible to do in the PHP/Apache module? 2. HTTP/2 response push and WebSocket 2.1 State of the art and Native HTTP server Another important feature is the push feature. How would it be possible to implement in further versions of PHP, without having to reimplement the HTTP server like the ReactPHP[4] project? Considering the fact that there is no enterprise-ready and performant application loop manager integrated natively in PHP core (using either forked or asynchronous), like Node.js's libuv, these solutions are destined for very small APIs and applications. Since PHP 5.3, there is the -S option for starting an internal HTTP server. Isn't there any plans to map this server to an userland API? This server has in fact all the logic needed by applications like ReactPHP[4], which has to reimplement it(!). Shouldn't there any other solution planned in PHP 7.x? 2.2. Solution 1: Implementing server from the ground with OS abstraction and application loops Solution of implmeenting from the ground the HTTP server is what ReactPHP did and is for now the most used solution. Some would say that these issues should be kept in the userland, but please, read to the end. Furthermore, integrating in the core an OS-abtracted API for process management and asynchronous I/O could be a big performance jump, with an extension being to ext/pcntl what PDO has been to ext/mysqli in PHP 5.x. As I wrote previously, Node.js has libuv which started as an abstraction layer for Node's to libev and Windows and became a full featured OS abstraction layer for process and I/O management. Shuhei Tanuma (with the help of other contributors) has implmented an experimental binding named ext/uv[5] that could be a start to implment a similar feature set in PHP. I used it for a while in a personal and experimental project, it is functional despite of some (very rare) crashes (and IMO a missing OOP-style API, which is more a personal taste than an issue). In the same vein, we have pcntl[6], eio[7], ev[8], libevent[9], pthreads[10], working in their own way but no uniform API, some use functional style, others are OOP style and there is maybe interoperability issues and feature overlapping (I did not test all of them in a single project). Some even aren't integrated in the standard release and are availiable on PECL only. As long as all these features are currently in extensions or in a SAPI, why wouldn't it be integrated in an unique extension/API? The changes in the SI architecture between PHP and the web server would be to transform the CGI interconnections to classical HTTP proxy connections. 2.3. Solution 2 : Define some other way, extending the SAPIs and/or the CGI API I can't tell if it is even possible to implment this, as long as the current architecture depends on the underlying layer sollicitations (HTTP server/CLI/ect...). Currently, PHP itself doesn't decide to send some data to the client such as push features, it must wait for its caller to be invoked, or manage the full application stack. Maybe it is all the request lifecycle that has to be rethought from the ground as an application of 2015 is radically different from a 1995 application (or even from 2005). 3. Conclusion Maybe there are
