RE: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately - thanks Oracle)
Hi Anatol, you may know that I am the maintainer of the NSAPI SAPI module. I spent a lot of time in improving it. The next update would have been to change it to the PHP 7 threading model, but based on recent experience with Oracle, I will stop maintaining the plugin. We should not remove it from PHP 5, but it should no longer be available for PHP7. The reason for this decision is: - Oracle seems to no longer have any interest in maintaining any public accessible developer downloads, you can now only order the product and download installation files (and therefore header files) through their paywall. All references to the OTN (Oracle Technology Network, means developer licenses) downloads were removed completely from their web pages. This happened after I asked a question on their support forums (which was moderated away), where the OTN downloads for the latest version including TLS 1.2 support are located now. This lead to the fact that they disabled the download page completely (and my post was moderated away, which is a really bad behavior, sorry I have to say this!). Somebody there should have known that I am the person who worked closely together with the people working on the iPlanet/Sun Webserver at Sun Microsystems times. This is annoying. - I am also phasing out use of this webserver privately, because the new conditions are unacceptable. In my opinion, this webserver was a great piece of nice and fast software, including - next to PHP - Java web application support inside the webserver, so there was no need to have stuff like reverse proxies needed (the usual Tomcat behind a reverse proxy Apache), because the Java code was running inside the web server (and this made it very fast). Of course, PHP support (when used through the NSAPI plugin) was great, too, because there was no overhead (although some PHP extensions were not compatible, because this webserver runs in a multithreaded way). People that still want to stay on iPlanet webserver can fallback to using FastCGI, which has some pitfalls, but generally works. The NSAPI plugin allowed to do much more like binding PHP script to directory (allowing to make custom PHP-based directory listings), or error pages. This is impossible using FastCGI as far as I know. I am sorry, I have to stop supporting it, because Oracle killed the last piece of good software :-( If there needs to be some decision about removing this plugin through an RFC, I can trigger one, but to me the above changes in Licensing make it impossible to longer support this piece of software. Uwe Thanks for the information. It's of course sad. I personally was hoping to be able to work and debug with one more real multi-threaded SAPI besides Apache. But so is the life. We've already had the NSAPI SAPI in the RFC suggesting removals https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#sapinsapi . As preparations I was building and testing every item in that RFC I could get my hands on. But for sapi/nsapi I couldn't get the environment already at that time, so I wasn't able to test it. It's senseless to guess how this item would have been voted. But with the addition of the knowing you shared today it looks pretty much that we should not carry it with PHP7. If one even cannot get the dependency library, except one has to buy it, it's a blocker. Well, except one wants to buy it :) Now, as that was the RFC I was working on, here are the steps I would suggest. Maybe there were a chance to ask for an exception for PHP project, you personally or whatever (if you're still interested)? As I described in my post before, I am a little bit annoyed becaue of Oracle's behaviour. I was just asking for a more up-to-date developer download on their forum around iPlanet web server. The reaction to that was: - initially the post was automoderated (review) - that's just fine - after a few days (when I came back to the forum), the web interface notified me that my post was blocked by a moderator. - in parallel to that, the download to the older version (v7.0.15) was removed! To me this looks like (this is just some: - Oracle wasn't aware that there was still a download to the older version (it was also hidden on their web page, you had to know what to enter into Google). - My forum request triggered a review of their web page - they removed the downloads - By post was blocked to hide that fact, that it was available in earlier times (and they maybe did not know). - All other questions from other people about where to download the newer version were answered with an Oracle patch ID #foobar and a link to the paywall (those questions were without reference to free OTN downloads, so they were not blocked by moderator). Because of this really bad behavior, I am a bit annoyed. Maybe they can fix this, but I would like to have a reaction from their side. I would then try to
RE: [PHP-DEV] Allow __toString() to throw exceptions
Hey, I have a question: is there any reason to throw an exception from __toString, *other* than a non-recoverable error, which would denote that the object, which the __toString method is called on, does not have any meaningful string representation? Because if not, core implementation fully serves its purpose throwing Fatal error now, even if it is non-standard way. The problem with not enabling __toString to throw exceptions is that if any exceptions thrown are by the engine itself (for things like uncallable functions), then the method returns an unrelated E_ERROR regarding the inability to throw exceptions. The code example [1] shows this where the old message was: Fatal error: Call to undefined function a() in... and now after the inclusion of exceptions in the engine, it is: Fatal error: Method Test::__toString() must not throw an exception in... This is obviously not an overly helpful response, and the E_ERROR cannot be caught either. Thanks, Tom [1] http://3v4l.org/eGc1d -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Throwable Interface
On 05/23/2015 10:12 PM, Aaron Piotrowski wrote: Hello, I’ve created an RFC for modifying the exception hierarchy for PHP 7, adding Throwable interface and renaming the exceptions thrown from fatal errors. The RFC is now ready for discussion. RFC: https://wiki.php.net/rfc/throwable-interface https://wiki.php.net/rfc/throwable-interface Pull Request: https://github.com/php/php-src/pull/1284 https://github.com/php/php-src/pull/1284 I like this RFC! It's much more intuitive as the current BaseException approve. Some small notes: Backwards Compatibility |Throwable|, |Error|, |TypeError|, and |ParseError| will no longer be available in the global namespace. Where are the new classes and the interface located if it's not in the global namespace or do I muss something? If I remember right the TypeException/TypeError will be thrown in some cases of internal functions with strict argument count. In my opinion a missing argument or to much arguments has nothing to do with the type and should have it's own Exception/Error class. Aaron Piotrowski Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] JSON number to string
Hi, I would like to introduce my and Pasindu's RFC that proposes adding of new JSON options for converting number values to string when decoding and/or encoding: https://wiki.php.net/rfc/json_numeric_as_string Personally I'm not a big fun of these options because of their drawbacks (see RFC section about that) and because I think that Json Scheme is a better way to go. However I'm not sure when and if I have time for Json Schema implementation, so this could be useful for some users the meantime. That is especially case of JSON_FLOAT_TO_STRING for decoding (encoding is a bit weird at it requires usage ini precision to do something useful). That (decoding) seems like a sort of a variant of JSON_BIGINT_TO_STRING for floats. That will be probably the only option that I will be vote for. Cheers Jakub
Re: [PHP-DEV] [RFC] Throwable Interface
Hi Aaron, On Sun, May 24, 2015 at 5:12 AM, Aaron Piotrowski aa...@icicle.io wrote: I’ve created an RFC for modifying the exception hierarchy for PHP 7, adding Throwable interface and renaming the exceptions thrown from fatal errors. The RFC is now ready for discussion. RFC: https://wiki.php.net/rfc/throwable-interface https://wiki.php.net/rfc/throwable-interface Pull Request: https://github.com/php/php-src/pull/1284 https://github.com/php/php-src/pull/1284 Does this include internal function type errors? e.g. $ php -r 'var_dump(mt_srand(999));' PHP Warning: mt_srand() expects parameter 1 to be integer, string given in Command line code on line 1 NULL If not, please make these exceptions rather than E_WARNING. We need consistency here. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
RE: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately - thanks Oracle)
Hi Uwe, -Original Message- From: Uwe Schindler [mailto:theta...@php.net] Sent: Sunday, May 24, 2015 12:18 PM To: 'Anatol Belski'; 'Internals' Subject: RE: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately - thanks Oracle) Hi Anatol, you may know that I am the maintainer of the NSAPI SAPI module. I spent a lot of time in improving it. The next update would have been to change it to the PHP 7 threading model, but based on recent experience with Oracle, I will stop maintaining the plugin. We should not remove it from PHP 5, but it should no longer be available for PHP7. The reason for this decision is: - Oracle seems to no longer have any interest in maintaining any public accessible developer downloads, you can now only order the product and download installation files (and therefore header files) through their paywall. All references to the OTN (Oracle Technology Network, means developer licenses) downloads were removed completely from their web pages. This happened after I asked a question on their support forums (which was moderated away), where the OTN downloads for the latest version including TLS 1.2 support are located now. This lead to the fact that they disabled the download page completely (and my post was moderated away, which is a really bad behavior, sorry I have to say this!). Somebody there should have known that I am the person who worked closely together with the people working on the iPlanet/Sun Webserver at Sun Microsystems times. This is annoying. - I am also phasing out use of this webserver privately, because the new conditions are unacceptable. In my opinion, this webserver was a great piece of nice and fast software, including - next to PHP - Java web application support inside the webserver, so there was no need to have stuff like reverse proxies needed (the usual Tomcat behind a reverse proxy Apache), because the Java code was running inside the web server (and this made it very fast). Of course, PHP support (when used through the NSAPI plugin) was great, too, because there was no overhead (although some PHP extensions were not compatible, because this webserver runs in a multithreaded way). People that still want to stay on iPlanet webserver can fallback to using FastCGI, which has some pitfalls, but generally works. The NSAPI plugin allowed to do much more like binding PHP script to directory (allowing to make custom PHP-based directory listings), or error pages. This is impossible using FastCGI as far as I know. I am sorry, I have to stop supporting it, because Oracle killed the last piece of good software :-( If there needs to be some decision about removing this plugin through an RFC, I can trigger one, but to me the above changes in Licensing make it impossible to longer support this piece of software. Uwe Thanks for the information. It's of course sad. I personally was hoping to be able to work and debug with one more real multi-threaded SAPI besides Apache. But so is the life. We've already had the NSAPI SAPI in the RFC suggesting removals https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#sapinsapi . As preparations I was building and testing every item in that RFC I could get my hands on. But for sapi/nsapi I couldn't get the environment already at that time, so I wasn't able to test it. It's senseless to guess how this item would have been voted. But with the addition of the knowing you shared today it looks pretty much that we should not carry it with PHP7. If one even cannot get the dependency library, except one has to buy it, it's a blocker. Well, except one wants to buy it :) Now, as that was the RFC I was working on, here are the steps I would suggest. Maybe there were a chance to ask for an exception for PHP project, you personally or whatever (if you're still interested)? As I described in my post before, I am a little bit annoyed becaue of Oracle's behaviour. I was just asking for a more up-to-date developer download on their forum around iPlanet web server. The reaction to that was: - initially the post was automoderated (review) - that's just fine - after a few days (when I came back to the forum), the web interface notified me that my post was blocked by a moderator. - in parallel to that, the download to the older version (v7.0.15) was removed! To me this looks like (this is just some: - Oracle wasn't aware that there was still a download to the older version (it was also hidden on their web page, you had to know what to enter into Google). - My forum request triggered a review of their web page - they removed the downloads - By post was blocked to hide that fact, that it was available in earlier times (and they maybe did not know). - All other questions from other people about where to download the newer version were
Re: [PHP-DEV] [RFC] Throwable Interface
On May 24, 2015, at 2:08 PM, Marc Bennewitz dev@mabe.berlin wrote: Where are the new classes and the interface located if it's not in the global namespace or do I muss something? Sorry if what I wrote wasn’t clear. Throwable, Error, TypeError, and ParseError will be built-in interfaces/classes in the root namespaces. So users will not be able to make classes with those exact names, but classes with those names in a non-global namespace (e.g., \Vendor\Package\TypeError) will still be possible. I’ve updated the RFC to make this clearer. If I remember right the TypeException/TypeError will be thrown in some cases of internal functions with strict argument count. In my opinion a missing argument or to much arguments has nothing to do with the type and should have it's own Exception/Error class. I believe this actually generates a warning, it does not throw an exception. However, this does remind me of another point: It is possible that more classes extending Error could be created in the future for different error reasons. Anything that throws an Error could later be changed to throw an object extending Error without a BC break. This is a separate issue though and could be discussed in a future RFC. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Fwd: [PHP-DEV] [RFC] [PHP 7.1] libsodium
I don't think that's a good idea. There are already production systems that call it like \Sodium::function_here(). I'm not an extension developer; I don't know what level of effort would even be required to refactor it from a class with static methods to a namespace with functions. And when you consider the amount of effort you're asking the developers who are already using the existing method, it doesn't seem worth it anyway. What is your reason for wanting to change Sodium to a namespace and all methods to functions? Especially as someone who, presumably, has never used the library before. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises https://paragonie.com On Fri, May 22, 2015 at 2:26 AM, Michael Wallner m...@php.net wrote: On 21/05/15 09:49, Peter Petermann wrote: Hi Scott, I personally think the RFC is a bit short, also I just had a very brief look at the documentation of the extension in question, and find its API a bit strange, whats up with having everything in static method calls? regards, PP 2015-05-21 3:15 GMT+02:00 Scott Arciszewski sc...@paragonie.com: The current state of cryptography in PHP is, well, abysmal. Our two main choices for handling symmetric cryptography are libmcrypt (collecting dust since 2007) and openssl, which lacks a streaming API (e.g. mcrypt_generic) and GCM support. I think now is a good time to talk about the possibility of making libsodium a core PHP extension, depending on where things are when we near the 7.1 feature freeze. I've just opened an RFC for precisely this purpose: https://wiki.php.net/rfc/libsodium Yes, the choice of API looks pretty awkward; if we could settle on PHP-5.6+, change Sodium to a namespace and all methods to functions therein. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: VCS Account Request: buhlerax
On Sun, May 24, 2015 at 5:51 AM, Alexandre Pereira Bühler alexan...@simaoebuhler.com.br wrote: On 05/05/2015 02:52, PHP Group wrote: VCS Account Approved: buhlerax approved by rasmus \o/ Desire updates the website page http://gtk.php.net/ but I can not perform a push. My karma only allows cloning. git returns error: remote: Welcome buhlerax remote: You have insufficient Karma! remote: I'm sorry, I cannot allow you to write to remote: web/gtk.git/resource.git to g...@git.php.net:/web/gtk.git How do I have a karma in http://git.php.net/?p=web/gtk.git;a=summary allowing the creation of branch and perform push? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I've granted you karma to the gtk-web repo, it takes a bit time for this to take into effect, but you should be able to push your changes in like half an hour. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
