Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:81647 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38608 invoked from network); 2 Feb 2015 20:20:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2015 20:20:33 -0000 Authentication-Results: pb1.pair.com smtp.mail=thetaphi@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=thetaphi@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.25.204.22 as permitted sender) X-PHP-List-Original-Sender: thetaphi@php.net X-Host-Fingerprint: 85.25.204.22 serv2.sd-datasolutions.de Received: from [85.25.204.22] ([85.25.204.22:53724] helo=mail.sd-datasolutions.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2E/C2-25089-01CDFC45 for ; Mon, 02 Feb 2015 15:20:33 -0500 Received: from VEGA (unknown [89.204.153.190]) by mail.sd-datasolutions.de (Postfix) with ESMTPSA id 9402D16F80325 for ; Mon, 2 Feb 2015 20:20:24 +0000 (UTC) X-NSA-Greeting: Dear NSA, have fun with reading and analyzing this e-mail! To: "'PHP internals'" References: <2ebcb8f91e4185726e4bf49d5e675c2a.squirrel@webmail.klapt.com> In-Reply-To: <2ebcb8f91e4185726e4bf49d5e675c2a.squirrel@webmail.klapt.com> Date: Mon, 2 Feb 2015 21:20:16 +0100 Message-ID: <01bf01d03f25$adcf53d0$096dfb70$@php.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLElAuehyeo7AQDrAIjMEKkjC4o7QHFkfQzAm8cWF8B+it35QH0AbzUmrQMSYA= Content-Language: de Subject: RE: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions From: thetaphi@php.net ("Uwe Schindler") Hi, I gave my votes (where I can talk about). I am still maintaining the = NSAPI SAPI. It does not meant that its dead if no commits were made. = NSAPI upstream API just did not change since years, so why change a = running system? The current version of this SAPI (5.6) runs perfectly with MediaWiki and = several CMS systems on latest Oracle iPlanet server in production. The = information about NSAPI you gave ("The developers of iPlanet @Oracle = wrote back, that they're not intended to support this SAPI starting from = PHP7 onwards.") is not applicable, because people from Sun/Oracle never = provided any support or this extension - you should have asked the = maintainer (me). Oracle just recommends fcgi, because it might be more = stable if you use non-threadsafe extensions, but otherwise the server is = perfectly stable and very fast. Oracle employees only helped with one = patch, otherwise it was mostly (re-)written by me. In addition, the = server works perfectly fine on Ubuntu 14.04, so it will also run on = Debian. It can be downloaded with Oracle OTN license, header files are = included. You can compile PHP 5.6 with it as documented: = http://www.oracle.com/technetwork/java/webtier/downloads/iplanet-webserve= r-525365.html If there are changes needed in the SAPI for PHP 7, I can take care, I = just have not looked into it. It should not be a problem for me to = update it, unless significant changes in the PHP API occurred since my = last commit (yes, I am a bit inactive, but still following the = development). Uwe ----- Uwe Schindler thetaphi@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany > -----Original Message----- > From: Anatol Belski [mailto:anatol.php@belski.net] > Sent: Monday, February 02, 2015 8:45 PM > To: Andrey Andreev > Cc: Nikita Popov; Anatol Belski; PHP internals > Subject: Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 = ported > SAPIs and extensions >=20 > On Mon, February 2, 2015 20:30, Andrey Andreev wrote: > > Oh, forgot one thing ... > > > > > > Mcrypt might be dead, but removing it would be a huge BC break. = There > > was some talk of binding mcrypt_*() functions to ext/openssl - I'd = suggest > > that instead of removal. > > > that sounds plausible, but the same one could say about mapping to be > removed regex to pcre. If anything of that is going to be happening, = so I > would welcome another RFC and implementation. >=20 > Regards >=20 > Anatol >=20 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php