On 16/08/16 02:11, Kalle Sommer Nielsen wrote: > 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?
There have been several 'attempts' to drop ext/interbase, all well documented on this list. PHP developers may not think Firebird is very popular, and probably from a PHP base it isn't but it IS used extensively in large areas of the World. 40 years ago I could tell clients what line of code to change while on the phone. 15 years ago when I was looking to augment proprietary code with web based, and PHP seemed the natural stepping stone so I started using PHP5 in parallel with C/C++ based systems. These days I'm lucky is I can remember if a job was in C or PHP let alone what module or function will fix a problem. BUT I did sit down with a clean copy of the source code and my hg based DVCS allowed me to produce a set of guide lines from the postgres driver as to the mods needed to bring the interbase one up to date. I spent the best part of a week back last December trying to make progress, but that is when https://gist.github.com/laruence/f3af903012902818d7da was pointed out as an alternative approach and I rolled back and started again from that. Xinchen Hui put some fixes in based on my testing and I believe that was what was pushed back in January. My hg mirror has finally synced over night and come up with a couple of clashes on the test files, but I understand those differences since any GOOD Firebird developer will tell you that creating a database on the fly is a security risk and Firebird is essentially designed to work with an existing one rather than creating dummy ones while testing! My tests always use an existing test database. > 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? We ... the Firebird community ... are trying to provide the support, but earning money is perhaps a more pressing use of time these days :( And simply trying to get PHP5.2 systems to run on later PHP's is just another hold up on any progress to new code! >> 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. The only problem at that time was the M$ way of working. Pierre would not use the firebird client library unless it was rebuilt with the same tools as the php builds, but the whole point of a client library was to match different systems. Even today the client library that ext/interbase uses is compiled for the engine compile rules rather than the PHP ones. Especially on Windows. > 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? TIME ... I still have some 30% of my clients on PHP5.2 - with Firebird 1.5 and yet every system that I've moved to PHP5.6 needs checking on every update because it's still not uncommon for something to pop up and cause problems. TODAY I am working on a total overhaul of the form management system used with bitweaver in order to keep my best client happy. Hence the discussion on 'simple variable'. To be honest I don't care what way PHP goes on handling variables as I think I now have a working setup, but it WOULD be nice if all that effort was more readily usable by many PHP users. -- 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
