Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81687
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)
Message-ID: <0d436102ec3afeeb91673e2d30c64de4.squirrel@webmail.klapt.com>
In-Reply-To:
 <CADajX4DwhhPudqixn7Ck=LUKX9XH4mpdFgvADhF0tmXMPTYueQ@mail.gmail.com>
References: <cef015a176ff63284f81af24f1e3d774.squirrel@webmail.klapt.com>
    <CADajX4DwhhPudqixn7Ck=LUKX9XH4mpdFgvADhF0tmXMPTYueQ@mail.gmail.com>
Date: Tue, 3 Feb 2015 09:08:38 +0100
To: "Adam Harvey" <aharvey@php.net>
Cc: "Anatol Belski" <anatol.php@belski.net>,
 "PHP internals" <internals@lists.php.net>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported
 SAPIs and extensions
From: anatol.php@belski.net ("Anatol Belski")

Hi Adam,

thanks for the explanations.

On Tue, February 3, 2015 08:10, Adam Harvey wrote:
> On 3 February 2015 at 03:11, Anatol Belski <anatol.php@belski.net> wrote:
>
>> properly after the voting phase the
>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
>> voting. Each item is voted separately. The voting ends on 2015-02-09 at
>> 21:00 CET.
>>
>
> To explain my -1s:
>
>
> - ext/imap and ext/mcrypt: while I realise that the underlying
> libraries are dead, these extensions are too widely used to straight up
> remove them, I fear — we don't have obvious alternatives with simple
> enough APIs that we can push users towards. I'd strongly support and
> encourage a reimplementation of these extensions (in C or PHP) around
> something supported if someone was able to step up and do the work,
> otherwise yes, I'll pitch in to do the minimal work to port these to 7.0
> if required.
For ext/imap I can point to this old thread:
http://grokbase.com/t/php/php-internals/141zh29xs2/ext-imap-bye-bye-in-php-5-6

And at list this one living native PHP implementation
https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
more library links in the older thread link above).

With ext/mcrypt there are also libs, I can point at least to this one

https://github.com/phpseclib/phpseclib

which was available even before PHP5.3 i think. Interestingly it can rely
on ext/mcrypt if available, otherwise it uses native PHP implementations.

Though note that those both are already ported, they landed in the RFC
exactly because of the dead dependency libraries.

I can just enclose myself to the reimlementation/surrogate layer idea.
Actually that would make sense also for the ext/regex which was voted to
be removed in another RFC. Otherwise, i'd rather advise users to use the
native PHP implementations.

> - ext/pdo_dblib: ODBC is almost always the better way of interfacing
> with SQL Server, but I don't think keeping this one around is doing anyone
> much harm (as opposed to ext/mssql, which we should kill with fire for the
> same reasons as ext/mysql).

There's also the sqlsrv extension
http://www.microsoft.com/en-us/download/details.aspx?id=20098 . I had no
chance to check ext/pdo_dblib but it's stated as not ported yet on the
PHPNG wiki page.

> Abstentions:
>
>
> - sapi/apache2filter: I wonder if someone would step up for that one
> if we advertised more widely, given I believe that it is in actual use.
> Unlike most of the other SAPIs, which are obviously dead, I'd
> like to give this one a bit more time before the 7.0 feature freeze.
>
No movement on this so far in the PHP7 direction. Nobody is porting it,
nobody is asking for that.

> - sapi/milter: I'm at least passingly familiar with almost all of the
> Web servers in the list, but I know nothing about the environments
> this SAPI is used in. Can someone who is familiar with it describe the pros
> and cons to dropping it?
>
It's a very exotic thing. As mentioned in the RFC, with this you can hook
into the MTA process. But the PHP script is invoked fromwithin the MTA.

> - ext/sybase_ct: does PDO (via dblib and/or ODBC) cover this
> functionality adequately? I feel that I know enough to vote on SQL Server
> related topics, but haven't looked at actual Sybase for years.
>
Basically the same as apache2filter - no movement on this towards PHP7.
Nobody is porting it, nobody is asking for that. If there are no constant
maintainers for this, IMHO porting it once which is doable, won't bring
anything good but tons of subtle bugs. Porting it once without real
maintanance and usage, just because we want to have "sybase" in, i mean.

I'm really curious about the stats after this RFC, which extensions/sapis
turned out to have found a new home and maintanance somewhere like PECL :)

Regards

Anatol