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
Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
Hi Uwe,
-----Original Message-----
From: Uwe Schindler [mailto:thetaphi@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
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.
UweThanks 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 look into this and help you with updating to new TLS API. This was one reason why I did this request to their forum, to get up-to-date Windows and Linux downloads.
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?
I still have access to the iPlanet libraries and I also have a download of version 7.0.15 for Linux - I can share the download (but this could be illegal, not sure). But I have no Windows version anymore, sorry.
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.
OK, this looks fine. Maybe we should involve Oracle people. Unfortunately, I have no direct contact regarding iPlanet.
I have good contacts to the Oracle Quality Assurance team in Ireland, but that is regarding Java. But those people are not responsible to this issue.
Uwe
Hi Uwe,
-----Original Message-----
From: Uwe Schindler [mailto:thetaphi@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.
UweThanks 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 look into this and help you with updating to new TLS API. This was one
reason why I did this request to their forum, to get up-to-date Windows and
Linux downloads.
I saw your temper in the first mail. But also that you were ready to support it if possible. As the irritation can go by, but the software stays. Would make me feel same as you actually.
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?I still have access to the iPlanet libraries and I also have a download of
version 7.0.15 for Linux - I can share the download (but this could be illegal,
not sure). But I have no Windows version anymore, sorry.
I think having only one version even for both Linux/Windows were not enough, as one would need to catch up with the eventual updates. Even more, as the Windows part is missing. So we were possibly not able to reproduce and fix bugs. So probably a dead end. At this point this is objectively the main blocker.
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.OK, this looks fine. Maybe we should involve Oracle people. Unfortunately, I
have no direct contact regarding iPlanet.
I have good contacts to the Oracle Quality Assurance team in Ireland, but
that is regarding Java. But those people are not responsible to this issue.
At the time I was investigating on the RFC, there already was a negative answer from the iPlanet team. So we already knew at that time they won't support it, it's stated in the RFC.
Regards
Anatol
Hi,
OK, this looks fine. Maybe we should involve Oracle people.
Unfortunately, I have no direct contact regarding iPlanet.
I have good contacts to the Oracle Quality Assurance team in Ireland,
but that is regarding Java. But those people are not responsible to this
issue.At the time I was investigating on the RFC, there already was a negative
answer from the iPlanet team. So we already knew at that time they won't
support it, it's stated in the RFC.
Yes. But they never ever supported the plugin "actively", so this was no real news at the time of the RFC. The SAPI was originally written by Jayakumar Muthukumarasamy, I took over in 2003. At that time there was no FastCGI support in the webserver, so the NSAPI plugin was the only working solution - and a great one (with just the well-known TLS problems, which was PHP's fault, not Sun/Oracle's). I improved it to be as most compliant to the Apache SAPI - it (still) works fine with most Content Management systems and MediaWiki (if you manage to make Rewrite rules of Apache working, that those CMS mostly need; this was fixed in iPlanet 7, where you can have rewrite rules - just with other syntax).
In my personal opinion: If you have contact to iPlanet people at Oracle, maybe you should contact them again (or send me the contact details). If they would provide a working (developer) download location for the latest 7.0.21 version (released a month ago with TLS 1.2 support), we could start supporting it. But without any download location, it is impossible to support it. You should also remind them: Although they recommend to use FastCGI, it is impossible to support this webserver from our side without a "developer download" to test. So we can verify that FastCGI works. I would like to have support for handling error pages with FastCGI (so you can present 404 not found pages using PHP or directory listings). All this was possible with the NSAPI plugin, but to test this out with iPlanet and FastCGI we would need a download location.
But if they show no interest, let NSAPI die :-(
Uwe
Hi!
But if they show no interest, let NSAPI die :-(
I would say let's set a defined point in time (like, 1 month from now),
by which if we don't hear anything from anybody at Oracle indicating
they have any interest in working with PHP we remove it (we can always
add it back if it changes). Also, did anybody check about it with Chris
Jones - he's at Oracle, maybe he knows somebody who could check about this?
--
Stas Malyshev
smalyshev@gmail.com
Hi Stas,
-----Original Message-----
From: Stanislav Malyshev [mailto:smalyshev@gmail.com]
Sent: Thursday, May 28, 2015 7:59 PM
To: Uwe Schindler; 'Anatol Belski'; 'Internals'; thetaphi@php.net
Subject: Re: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately -> thanks
Oracle)Hi!
But if they show no interest, let NSAPI die :-(
I would say let's set a defined point in time (like, 1 month from now),
by which if we don't hear anything from anybody at Oracle indicating
they have any interest in working with PHP we remove it (we can always
add it back if it changes). Also, did anybody check about it with Chris
Jones - he's at Oracle, maybe he knows somebody who could check about
this?
Yeah, Chris did forward this topic to someone @Oracle on Monday (but that was a holiday in many countries). So we're on hold waiting for the answer.
Regards
Anatol
Hi,
We've just got the answer from the person responsible for the NSAPI related product management. The SDK on which sapi/nsapi depends won't be available. Thus, we won't be able to support NSAPI further anymore. I'm going to tag away sapi/nsapi next days in the same manned it was done for the rest of the removals RFC, so the code will be available in that tag.
Uwe, I'm sad with you.
Regards
Anatol
-----Original Message-----
From: Anatol Belski [mailto:anatol.php@belski.net]
Sent: Thursday, May 28, 2015 8:46 PM
To: 'Stanislav Malyshev'; 'Uwe Schindler'; 'Internals'
Subject: RE: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately -> thanks Oracle)Hi Stas,
-----Original Message-----
From: Stanislav Malyshev [mailto:smalyshev@gmail.com]
Sent: Thursday, May 28, 2015 7:59 PM
To: Uwe Schindler; 'Anatol Belski'; 'Internals'; thetaphi@php.net
Subject: Re: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately -> thanks
Oracle)Hi!
But if they show no interest, let NSAPI die :-(
I would say let's set a defined point in time (like, 1 month from
now), by which if we don't hear anything from anybody at Oracle
indicating they have any interest in working with PHP we remove it (we
can always add it back if it changes). Also, did anybody check about
it with Chris Jones - he's at Oracle, maybe he knows somebody who
could check about this?Yeah, Chris did forward this topic to someone @Oracle on Monday (but that was
a holiday in many countries). So we're on hold waiting for the answer.Regards
Anatol
--
To unsubscribe, visit:
http://www.php.net/unsub.php