RIP: NSAPI SAPI Plugin (unfortunately -> thanks Oracle)

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.
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 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