Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86350
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Uwe Schindler'" <thetaphi@php.net>,
	"'Internals'" <internals@lists.php.net>
References: <08a701d0946c$176c3290$464497b0$@php.net>
In-Reply-To: <08a701d0946c$176c3290$464497b0$@php.net>
Date: Fri, 22 May 2015 19:05:01 +0200
Message-ID: <01f301d094b1$7359c690$5a0d53b0$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGlqNlaCOT7//WFvEh2FQRtYNJ2c53eALvA
Content-Language: en-us
Subject: RE: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately -> thanks Oracle)
From: anatol.php@belski.net ("Anatol Belski")

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)
>=20
> Hi,
>=20
> 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.
>=20
> The reason for this decision is:
>=20
> - 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.
>=20
> - 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).
>=20
> 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.
>=20
> I am sorry, I have to stop supporting it, because Oracle killed the =
last piece
> of good software :-(
>=20
> 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
>=20
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