Hi Uwe, > -----Original Message----- > From: Uwe Schindler [mailto:theta...@php.net] > Sent: Friday, May 22, 2015 10:49 AM > To: Internals > Subject: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately -> thanks Oracle) > > Hi, > > 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)? Else, I would do the last call for someone with the access to iPlanet libraries who is ready to port maintain sapi/nsapi in PHP7. If there is one, we're all fine. Someone? Else I would suggest to remove sapi/nsapi from the PHP7 branch by gathering a simple consent here on the lists. If any objections are raised, then the RFC way needs to be hit. It makes probably little sense to leave something not ported after so many cleanups was already done. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
