Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95221 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30378 invoked from network); 15 Aug 2016 23:27:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Aug 2016 23:27:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.230 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.230 mail4-3.serversure.net Linux 2.6 Received: from [217.147.176.230] ([217.147.176.230:55659] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 37/AF-36656-5EF42B75 for ; Mon, 15 Aug 2016 19:27:35 -0400 Received: (qmail 3588 invoked by uid 89); 15 Aug 2016 23:27:31 -0000 Received: by simscan 1.3.1 ppid: 3576, pid: 3582, t: 0.0881s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 15 Aug 2016 23:27:31 -0000 To: internals@lists.php.net References: <53c8bb5d-3d60-6019-d089-93d0285bb8ff@lsces.co.uk> Message-ID: Date: Tue, 16 Aug 2016 00:27:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] orphan extensions cleanup From: lester@lsces.co.uk (Lester Caine) On 15/08/16 23:50, Kalle Sommer Nielsen wrote: > 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. 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 :( 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! 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 ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk