2016-08-16 1:27 GMT+02:00 Lester Caine <les...@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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
