Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86362
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.25.204.22 as permitted sender)
To: "'Anatol Belski'" <anatol.php@belski.net>,
	"'Internals'" <internals@lists.php.net>
References: <08a701d0946c$176c3290$464497b0$@php.net> <01f301d094b1$7359c690$5a0d53b0$@belski.net>
In-Reply-To: <01f301d094b1$7359c690$5a0d53b0$@belski.net>
Date: Sun, 24 May 2015 12:17:36 +0200
Message-ID: <0bb301d0960a$dbaf6a10$930e3e30$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGlqNlaCOT7//WFvEh2FQRtYNJ2cwHwXWs9ndE2qnA=
Content-Language: de
Subject: RE: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately -> thanks Oracle)
From: thetaphi@php.net ("Uwe Schindler")

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.
>=20
> 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.
>=20
> 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 :)
>=20
> Now, as that was the RFC I was working on, here are the steps I would
> suggest.
>=20
> 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