Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104873 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 32172 invoked from network); 22 Mar 2019 17:17:51 -0000 Received: from unknown (HELO mail4.serversure.net) (185.153.204.204) by pb1.pair.com with SMTP; 22 Mar 2019 17:17:51 -0000 Received: (qmail 31283 invoked by uid 89); 22 Mar 2019 14:10:14 -0000 Received: by simscan 1.3.1 ppid: 31232, pid: 31280, t: 0.0869s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@lsces.co.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 22 Mar 2019 14:10:14 -0000 To: PHP internals References: Cc: fbdev list Message-ID: <95e918c8-aaeb-d700-cc08-30f10a07162d@lsces.co.uk> Date: Fri, 22 Mar 2019 14:10:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Unbundle ext/interbase From: lester@lsces.co.uk (Lester Caine) On 22/03/2019 13:26, Kalle Sommer Nielsen wrote: > G'day internals > > I'd like to start the discussion for the future of the ext/interbase extension: > https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase > > The rationale for pushing this extension out of the core is mentioned > in the RFC. > > Unless there is any serious issues raised here, then I will put this > into voting on Monday 8th of April, noon EET (which is a good two and > a half weeks away). The intended voting period is set for 2 weeks, > meaning if voting proceeds, the pools will be closed around Monday > 22th of April, noon EET. It is not that we don't want to stand up and maintain it, it has been impossible in recent years to get a handle on just what needs to be done TO maintain it. The PDO extension is in a much worse state than the main interbase one but both of them do their jobs as well as they can given that in the case of PDO it can't handle the cross database transactions, something that the main extension does quite happily. Personally I've been wasting time recently trying to keep alive sites that are using MySQL and the main problem with MySQL is the one thing that Firebird does nicely. Backup just runs as a secondary cron job independent of PHP while MySQL is reliant on PHP and current backups on some wordpress powered sites are failing because they run out of time or memory. I've never had a problem with loosing data with Firebird while I've had recover MySQL situations a few times in the last year! So all we are asking for is HELP with the code changes that result from changes to the PHP API to keep this available. -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk