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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
