Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95223
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
Sender: kalle.php@gmail.com
In-Reply-To: <b62916b1-8822-1593-f9d3-47bf98fbfcaf@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> <CAJW__o06BoPfQJaeRSzKtD5oB2hB5b16E4dgCw=aSpHxUoqRuQ@mail.gmail.com>
 <b62916b1-8822-1593-f9d3-47bf98fbfcaf@lsces.co.uk>
Date: Tue, 16 Aug 2016 03:11:23 +0200
Message-ID: <CAJW__o1Q9ZmLCaBds3HXbeTrbaHLTawsA=pxD0kQ6idNfx9dqw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] orphan extensions cleanup
From: kalle@php.net (Kalle Sommer Nielsen)

2016-08-16 1:27 GMT+02:00 Lester Caine <lester@lsces.co.uk>:
> None of the listed bugs are a problem in normal use. Some WERE fixed in
> previous code, but those fixes were not merged with the master code base
> in pre git days :(

So you are saying that in your patch for the PHP7 support for
ext/interbase, had some bugs fixed that is currently not merged into
the master? I do not see any such open PRs or bug reports, or remember
any such recent threads on internals about it, but now that it is
being suggested we remove ext/interbase, it comes up?


> I accept that 95% of changes are due simply to generic tidies/style
> changes that someone feels good about and it was one of those fixes that
> broke a few database extensions back in PHP5.0/1 days. It took a few
> versions to get interbase fixed then and I did sort of understand how
> THAT code worked, but all the ZEND complexity now overlaying the code
> makes picking up simple changes a LOT more difficult. MY attempt at the
> PHP7 changes where simply a mess which is why *I* asked for some help
> working out just how to rework the code. The primary interface to
> firebird and interbase has not changed in 20 years so the bulk of the
> actions ARE only broken by PHP changes! Although it may be an advantage
> to finally split firebird and interbase now that FB3 is out, there is no
> pressing reason to do that since all one is really doing IS passing
> queries to the engine and getting results sets back!

The Zend API is not that complex for extensions, it have not changed
too much. We have tons of extensions now at least, or had in the PHP7
development time that could be used as a base understanding of how
simple APIs are working. We also have an IRC channel that we use where
you can probably get some support too, or even StackOverflow's chat
might be of some help, heck even Twitter.

But I still fail to understand the point you are making, at first you
are talking about "WE" as being who? Us, the PHP Development Team? You
and your company? The Community?

The baseline is fairly simple, and I will try to say it as directly as
I can hopefully one last time; We cannot maintain an extension if
there is no one willing to step forward to work on it, someone who
understands its internals, have proper testing facilities and such, if
that is the case, which seems to have been for a semi long time for
Interbase, then it should *NOT* be in the core. If there is no one to
maintain it, and there are security issues in it, then it causes even
more problems for us, the PHP Development Team, if we continue to
redistribute the core PHP interpreter with an extension that can
potentially compromise a server, I'm not talking strictly about
Interbase, as I do not have the in-depth knowledge about it, but I'm
talking aboustract, whether its Interbase, BCMath or something third.


> I should probably actually test FB3, but in my production environments
> there is no pressing need to use that. I'm not expecting any problems
> with PHP, but if the driver needs compiling with a non interbase
> compatible client library, THEN we need to fork firebird and if we have
> to do what we did when Pierre dropped support from the driver in windows
> builds and supply an unsupported third party build so be it ...

If Pierre dropped support for a driver on Windows, there is probably a
good reason to do so. On the top of my mind, I can think of several
reasons why it could be a problem. Unsupported library, commercial
tools required, unsupported Windows version, ... the list goes on.

But a piece of advice, if you are so keen on keeping Interbase, and
the "WE" you are so often talking about, why do you not contribute to
the Core to see it keep its place? If its an internals support issue,
then we have some, although rough snippets on the wiki[1], the PHP.net
manual[2], The PHP Internals Book[3], Nikita also have some
interesting and in depth reads on his blog[4]. Although I do not know
how updated these are to PHP7, but it does give you some hints of
where to look for things and what to keep in mind, and in worst case,
then go to the source.

[1] https://wiki.php.net/internals
[2] http://php.net/internals2.ze1.zendapi
[3] http://www.phpinternalsbook.com/
[4] https://nikic.github.io/


-- 
regards,

Kalle Sommer Nielsen
kalle@php.net