Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82401
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.177 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <CAKxcST-HgaLO+EHh0xoxSefK4J3H2d1EMCWHD6z8O69oVL4m8Q@mail.gmail.com>
References: <bc6d032454578020cdd2cef172698534.squirrel@webmail.klapt.com> <CAKxcST-HgaLO+EHh0xoxSefK4J3H2d1EMCWHD6z8O69oVL4m8Q@mail.gmail.com>
Date: Wed, 11 Feb 2015 07:53:58 +0800
Message-ID: <CADajX4AGuQw55NzQA4Fz-53ya3OOAJzUM1Y4iO=+YwTF3OTezw@mail.gmail.com>
To: Paul Dragoonis <dragoonis@gmail.com>
Cc: Anatol Belski <anatol.php@belski.net>, PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7
 ported SAPIs and extensions
From: aharvey@php.net (Adam Harvey)

On 11 February 2015 at 06:59, Paul Dragoonis <dragoonis@gmail.com> wrote:
> On Mon, Feb 9, 2015 at 10:29 PM, Anatol Belski <anatol.php@belski.net>
> wrote:
>> ext/mssql              17:13
>
> Did you accidentally miss out mssql? it resultes in significant resistanc=
e
> to leave core, such as mcrypt and ignoring mathematical numbers, from a
> practical basis I'd like to see mssql kept in core. Who's with me ?

Since it's apparently my week for this, I'll provide the case for the
defence (or why I voted for removal, anyway):

- The API is awful in the exact same ways the ext/mysql API was awful
=E2=80=94 it makes it far harder to write secure code than it should be.

- Actually, it's worse than that, because there's no charset-aware
escaping function at all: the only option is addslashes(), which has
interesting security implications if you're using certain charsets.

- It's buggy. Some of the bugs are due to the underlying library
(which is mostly dead); some are in our code, but there are some
fundamental issues =E2=80=94 basic data types (nvarchar(128), for example)
aren't supported, field names are truncated, stored procedure calls
are problematic, and probably many more things that I've forgotten.

- The bugs probably aren't going to be fixed. ext/mssql averages about
one to two non-whitespace, non-copyright-year-increment commits a
year. A cursory look at the bug tracker (or my ##php logs) will tell
you that it's not because it's stable and free of bugs.

- There are multiple better options: using ODBC is almost always more
stable, and while PDO_dblib has some of the same problems due to
FreeTDS, at least you're using PDO's better (by which I mostly mean
harder to misuse) API.

In my mind, this is analogous to removing ext/mysql: it's the right
thing to do for our users because it promotes better practices and
gets rid of an extension that has even more technical issues than that
one did.

Finally, Anatol's tally was wrong for this one: it was 17:3 for
removal. That's a pretty strong indicator by itself.

Adam