Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80365 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67216 invoked from network); 11 Jan 2015 10:24:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jan 2015 10:24:54 -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.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:33756] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 54/72-48183-47F42B45 for ; Sun, 11 Jan 2015 05:24:52 -0500 Received: (qmail 24014 invoked by uid 89); 11 Jan 2015 10:24:49 -0000 Received: by simscan 1.3.1 ppid: 24008, pid: 24011, t: 0.0586s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.169.173.116) by mail4.serversure.net with ESMTPA; 11 Jan 2015 10:24:49 -0000 Message-ID: <54B24F71.8010704@lsces.co.uk> Date: Sun, 11 Jan 2015 10:24:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: internals@lists.php.net References: <54B1AA31.6050703@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files) From: lester@lsces.co.uk (Lester Caine) On 11/01/15 04:08, Sara Golemon wrote: > My idea is to cover *most* (but not all) extensions with a narrower, > simplified API. As you say, many interactions fall into the "marshal > this engine value to a C type as needed". This can cater to the > bread-and-butter of PHP extensions very well. Having a rather large reliance on Firebird, the fact that it gets pushed to the 'someone else will do that when they need it' pile is a little irritating. All the extension does is interfaces the Firebird Client to PHP and the majority of the times it has become unavailable are due to framework changes. Other extensions are currently in the same state on phpng? All database related. HHVM has only recently started supporting the interbase extension, but I think does not have the fbird_ aliases which while there is still no break between firebird and interbase, this is an area which will change with the next generation of Firebird. Alright we do have a couple of people who understand the PHP side enough to address the very small number of bugs that have affected the extension but it does need a programmer who understands the fundamental changes being made that is needed to port the still missing extensions :( I know you are only talking about the mechanism Sara, but some of us are still unable to even play with the current master on our framework because only 'most' extensions are currently supported. -- 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