Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95220
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.178 as permitted sender)
MIME-Version: 1.0
Sender: kalle.php@gmail.com
In-Reply-To: <53c8bb5d-3d60-6019-d089-93d0285bb8ff@lsces.co.uk>
References: <f790ef52-0a92-a8a3-bb3d-891713b390be@gmail.com>
 <CAF+90c8Qjze6ttRj1F0ZsX=aFfheuHZnLr7t0Y0D-SH79xS6jg@mail.gmail.com>
 <a2ab898f-9463-52c4-bfa1-2e80aa4decdb@lsces.co.uk> <CAJW__o1mchg7NymuKrWYxqeu6vVzP6pfyDEpFNNWrhKBJ0N5Bg@mail.gmail.com>
 <e83dfc59-a27b-9a29-3e4f-bbcf9cf0b6c2@lsces.co.uk> <CAJW__o3Cxu+xYJiO2ZjbU96HE5ro9GFB0-CHHR+Cf3-beT8WQg@mail.gmail.com>
 <53c8bb5d-3d60-6019-d089-93d0285bb8ff@lsces.co.uk>
Date: Tue, 16 Aug 2016 00:50:35 +0200
Message-ID: <CAJW__o06BoPfQJaeRSzKtD5oB2hB5b16E4dgCw=aSpHxUoqRuQ@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] orphan extensions cleanup
From: kalle@php.net (Kalle Sommer Nielsen)

2016-08-16 0:07 GMT+02:00 Lester Caine <lester@lsces.co.uk>:
> https://www.mail-archive.com/internals@lists.php.net/msg82170.html From
> December last year. *I* was under the impression that it was this work
> that was in the driver already after we had helped debug it!
> https://github.com/php/php-src/commits/master/ext/interbase Jan 8
> commits I think ... It will be a couple of hours before my local repo is
> back in sync and I can verify

Let's take a look at the last 70 commits made to ext/interbase, which
ranges from (January 3rd 2014 to now):

PHP internals changes not related to the extension, including merges
and other indirect changes: 61
Direct bug fixes and improvements: 9

Which is on a 2=C2=BD year commit log, that is a long time for an
extension, where we have 9 open bug reports, 3 of the assigned to
Mariuz, one even as old as 2009, that bug just had its 7th birthday in
Jan 2016.

My previous statement still stands, if there is no one to maintain
this in the core, it becomes a burden on everyone else, simply because
we are simply not able to maintain this code base anymore, that you
must be able to see yes?

> By the way ... sql.safe_mode switch was ONLY used to lock the database
> selection to the one defined in the ini file. The create database block
> was to prevent bypassing that lock by simply creating a new database -
> because you could not then access that database. This IS a BC change but
> only if ibase.default_db is not the only database setting visible. It
> would have made more sense to simply move it back to the ibase ini block
> and document the change.

Yes I do realize it is a BC change, I authored the patch. But as you
may also have noticed then this patch is for master only, which is PHP
7.2, that is probably first gonna be coming out in 2017 or 2018. But
it is off topic, so let that be or raise your concern in another
topic.


> Since PDO is a poor substitute for any of the generic drivers it's about
> time THAT was finally put to bed and a decent alternative provided.
> Firebird/Interbase is not the only driver that needs it's generic
> version to provide much of the heavy lifting that PDO can't handle.
> Currently the interbase driver is running clean on all my compatibility
> testing of PHP7 so what is the problem?

The problem that we are trying to solve here is that there is no one
to maintain those ways we have right now to collect to
Interbase/Firebird, how are we magically gonna provide some decent
alternatives if there is no one to even work on what we have in the
first place? That does not even make sense.



--=20
regards,

Kalle Sommer Nielsen
kalle@php.net