On 3 February 2015 at 03:11, Anatol Belski <anatol....@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.

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

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.

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

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

Adam

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to