Firebird - Who are WE ...

Over twenty years ago Borland took over Ashton Tate to bring dBase into
the Borland tool set. What they did not appreciate at the time was that
Ashton Tate had taken over Interbase to provide a proper multi-user
database engine to augment dbase. The bean counters at Borland decided
there was no margin in the Interbase part of Ashton Tate and announced
it would be end of lifed! They did not appreciate at the time just how
many people had moved from dbase over to Interbase and how many
businesses were then reliant on it. In a knee jerk reaction to calm
things down they offered to open source the code ... and long story
short Firebird came into existence. The bean counters THEN began to
realise what a cash cow Interbase could become or rather could have
become so the end of life was rescinded, but the the cat was already out
of the bag.

Roll forward 10 or so years and PHP drops the Interbase driver from the
windows builds. Well actually there were no official windows builds so
we had to rally around and provide them, but the drive to sort out
building PHP on the newer windows compile stacks saw the interbase
driver pushed to the side "because Firebird did not support compatible
builds!". So we just carried on providing them outside the PHP project
along with other key elements like imagick!

The key reason for not allowing Firebird into windows builds was that
it's client library was no compatible with the build set and that
Firebird needed to be compiled with the same version of windows
compiler. This did not make sense then just as it does not now. A
database engine is a stand alone section of code and may well be running
on a completely different machine so why should the version of windows
used make any difference ... if the server is on Linux? The important
bit is that the LOCAL client program can be linked to the local user -
in this case PHP. With the windows setup the interbase extension paired
with the firebird client and all that needed to be done to access a
newer Firebird server was to load the newer client onto the machine. The
link between the interbase extension and the firebird client has not
changed in many years. So today to switch from PHP connecting to a
production FB2.1 or FB2.5 to an FB3 machine we simply install the
correct client and do nothing with the interbase extension.

Today there are problems IN the interbase extension caused by the way
PHP now handles a 'resource' such as a database connection. Firebird
(and Interbase) has the ability to create transactions between two or
more active connections and commit or roll back all as required. PDO
does not allow multiple connections at all so there is no way to action
it via PDO so the interbase extension is the only way to access it. I
think that part of the problem of the way the resource handling has been
updated in the extension is down to not understanding this element and
yes someone who understands firebird needs to maintain this but it's the
way that PHP has changed the API which also needs to be understood.

I have tried to keep up to speed with the PHP side of things, but
having submitted fixes in the past, trying to decipher what Nikita is
trying to do in this latest patch is difficult looking at the code in
isolation since there are lots of 'system' calls that I don't follow.
Personally I don't need more than a single link to a single database so
everything still works for me anyway, but with persistent connections I
presume the resource links should be managed at a higher level anyway?

On my own development platform I think using hg-git to access the
php-src repository is now impossible. Since yesterday afternoon I've
downloaded 896 commits of the 24601 I'm behind, so while THG works
perfectly for all the key components such as ADOdb, smarty and ckeditor,
if I'm going to work with php code I'm going to have to bypass that!
Which is yet another learning curve when the one I am on works well to
provide the input that I do provide.

ADOdb has been kept up to date with the changes in questions and results
passed over the link but to date nothing major has changed in 20+ years
in the process of sending a query to the database and getting a result
set back ... although handing the new authentication methods added in
FB3 may benefit from a major rebuild of the extension, which WOULD
require that the fbird_ aliases are moved to their own build of the
extension, being completely incompatible with current builds of Interbase.

--
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

Hi

Den lør. 23. mar. 2019 kl. 11.28 skrev Lester Caine lester@lsces.co.uk:

Over twenty years ago Borland took over Ashton Tate to bring dBase into
the Borland tool set. What they did not appreciate at the time was that
Ashton Tate had taken over Interbase to provide a proper multi-user
database engine to augment dbase. The bean counters at Borland decided
there was no margin in the Interbase part of Ashton Tate and announced
it would be end of lifed! They did not appreciate at the time just how
many people had moved from dbase over to Interbase and how many
businesses were then reliant on it. In a knee jerk reaction to calm
things down they offered to open source the code ... and long story
short Firebird came into existence. The bean counters THEN began to
realise what a cash cow Interbase could become or rather could have
become so the end of life was rescinded, but the the cat was already out
of the bag.

Roll forward 10 or so years and PHP drops the Interbase driver from the
windows builds. Well actually there were no official windows builds so
we had to rally around and provide them, but the drive to sort out
building PHP on the newer windows compile stacks saw the interbase
driver pushed to the side "because Firebird did not support compatible
builds!". So we just carried on providing them outside the PHP project
along with other key elements like imagick!

The key reason for not allowing Firebird into windows builds was that
it's client library was no compatible with the build set and that
Firebird needed to be compiled with the same version of windows
compiler. This did not make sense then just as it does not now. A
database engine is a stand alone section of code and may well be running
on a completely different machine so why should the version of windows
used make any difference ... if the server is on Linux? The important
bit is that the LOCAL client program can be linked to the local user -
in this case PHP. With the windows setup the interbase extension paired
with the firebird client and all that needed to be done to access a
newer Firebird server was to load the newer client onto the machine. The
link between the interbase extension and the firebird client has not
changed in many years. So today to switch from PHP connecting to a
production FB2.1 or FB2.5 to an FB3 machine we simply install the
correct client and do nothing with the interbase extension.

Today there are problems IN the interbase extension caused by the way
PHP now handles a 'resource' such as a database connection. Firebird
(and Interbase) has the ability to create transactions between two or
more active connections and commit or roll back all as required. PDO
does not allow multiple connections at all so there is no way to action
it via PDO so the interbase extension is the only way to access it. I
think that part of the problem of the way the resource handling has been
updated in the extension is down to not understanding this element and
yes someone who understands firebird needs to maintain this but it's the
way that PHP has changed the API which also needs to be understood.

I have tried to keep up to speed with the PHP side of things, but
having submitted fixes in the past, trying to decipher what Nikita is
trying to do in this latest patch is difficult looking at the code in
isolation since there are lots of 'system' calls that I don't follow.
Personally I don't need more than a single link to a single database so
everything still works for me anyway, but with persistent connections I
presume the resource links should be managed at a higher level anyway?

On my own development platform I think using hg-git to access the
php-src repository is now impossible. Since yesterday afternoon I've
downloaded 896 commits of the 24601 I'm behind, so while THG works
perfectly for all the key components such as ADOdb, smarty and ckeditor,
if I'm going to work with php code I'm going to have to bypass that!
Which is yet another learning curve when the one I am on works well to
provide the input that I do provide.

ADOdb has been kept up to date with the changes in questions and results
passed over the link but to date nothing major has changed in 20+ years
in the process of sending a query to the database and getting a result
set back ... although handing the new authentication methods added in
FB3 may benefit from a major rebuild of the extension, which WOULD
require that the fbird_ aliases are moved to their own build of the
extension, being completely incompatible with current builds of Interbase.

I read this 800+ novel of words, and I still do not understand who
"we" are. Like are you kidding me, honestly. Can't you just say
whether it is "we" as in:

• The Firebird community
• The Interbase community
• or a combination?
• Borland?
• Aston Tate?
• The dBase developers?

80% of this posting is more a personal blog of how you (not "we") have
been interacting with the PHP community (as in the PHP.net community
specifically). What you should have done was to reply to either me or
Dan in the RFC thread with a one liner: "I mean 'We' as in X", that
would have been it.

Please! Keep these history lessons to your personal blog instead of
internals when there is zero relevance to the topic in question.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

80% of this posting is more a personal blog of how you (not "we") have
been interacting with the PHP community (as in the PHP.net community
specifically). What you should have done was to reply to either me or
Dan in the RFC thread with a one liner: "I mean 'We' as in X", that
would have been it.

We as in the people who rally around when we need to to protect the
things we think are important. There are more people today reliant on
elements like Firebird than there were 20+ years ago and to be honest if
you kick the interbase driver into PECL we will carry on using it
anyway, but YES it needs some love - from someone who can navigate
around just how resources have been changed in PHP7. The sort of
cooperation we had while keeping several extensions available on windows
in the past. I'm perfectly happy that I am not the only person using PHP
with Firebird .... and reliant on it continuing to be available!

Now to get back to working out why Nikita's patch does not work in
7.2.16 ...

--
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

Hi

Den lør. 23. mar. 2019 kl. 14.36 skrev Lester Caine lester@lsces.co.uk:

We as in the people who rally around when we need to to protect the
things we think are important. There are more people today reliant on
elements like Firebird than there were 20+ years ago and to be honest if
you kick the interbase driver into PECL we will carry on using it
anyway, but YES it needs some love - from someone who can navigate
around just how resources have been changed in PHP7. The sort of
cooperation we had while keeping several extensions available on windows
in the past. I'm perfectly happy that I am not the only person using PHP
with Firebird .... and reliant on it continuing to be available!

The point of putting it in PECL is for you to keep using it, if we (We
as in the PHP Development Team) did not care, it would have probably
have been removed entirely, which I personally do not believe is fair.

It is fine that you rally together, however it does not mean that we
(We as in the PHP Development Team) will change our stance unless you
bring someone to take over the extension.

To me personally, I will not halt the start of the vote unless there
is someone who stands up to take over the extension and posts some
relevant patches for it within the next 2 weeks (ish) to get it
working. We (we as in the PHP Development Team), will gladly do what
we can to welcome that aid, but after all this back and fourth and
lack of extension maintainer, I do not want to take the risk of
repeating the same loop once more, there has to be a limit.

Now to get back to working out why Nikita's patch does not work in
7.2.16 ...

Obviously because the patch was made for PHP 7.3. Hint: If a
macro/function is not available in 7.2, then look at how it is
implemented in 7.3 and migrate it or see how other functions who do
similar functionality works and port it.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

You say lots of people are relying on it, but it is only you who speaks in
support of it. The thing is broken, it does bad things, there is no
maintainer, and not a huge userbase.

It's not the case that we are just kicking it out for convenience, it is
the case that we cannot keep it in phpsrc with no maintainer and no
userbase, and no good reason for it to be in phpsrc.

The thing is more or less abandoned, and at this point, since it needs work
and a maintainer, the best thing to do is move it to PECL to free it from
the release cycle of PHP so that anyone may work on it and start creating
releases at their own pace, one that suits the community you say are using
it.

Cheers
Joe

80% of this posting is more a personal blog of how you (not "we") have
been interacting with the PHP community (as in the PHP.net community
specifically). What you should have done was to reply to either me or
Dan in the RFC thread with a one liner: "I mean 'We' as in X", that
would have been it.

We as in the people who rally around when we need to to protect the
things we think are important. There are more people today reliant on
elements like Firebird than there were 20+ years ago and to be honest if
you kick the interbase driver into PECL we will carry on using it
anyway, but YES it needs some love - from someone who can navigate
around just how resources have been changed in PHP7. The sort of
cooperation we had while keeping several extensions available on windows
in the past. I'm perfectly happy that I am not the only person using PHP
with Firebird .... and reliant on it continuing to be available!

Now to get back to working out why Nikita's patch does not work in
7.2.16 ...

--
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

The thing is broken

The BLOODY THING IS WORKING PERFECTLY ... what is broken is something
that simply currently necessitates using the resource that has already
been created rather than trying to connect again. The correct response
to someone complaining about it is as with many other things in PHP
simply to explain they are doing it wrong anyway.

--
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

No it is not, if it were, it would not need patching, it would not be doing
illegal things in ZTS mode and I wouldn't be getting shouted at by someone
not qualified to say if it works or not.

Consider me out of this conversation.

The thing is broken

The BLOODY THING IS WORKING PERFECTLY ... what is broken is something
that simply currently necessitates using the resource that has already
been created rather than trying to connect again. The correct response
to someone complaining about it is as with many other things in PHP
simply to explain they are doing it wrong anyway.

--
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

Now to get back to working out why Nikita's patch does not work in
7.2.16 ...
Obviously because the patch was made for PHP 7.3. Hint: If a
macro/function is not available in 7.2, then look at how it is
implemented in 7.3 and migrate it or see how other functions who do
similar functionality works and port it.

When merging the patch with the older code I was fairly sure that it did
exist already in 7.2 ... but until I can get php-src synced I'm having
to manually scan for this stuff ... at the current rate hg-git will take
24 days so now I need another plan of attack :(

--
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

Lester

lør. 23. mar. 2019 kl. 15.16 skrev Lester Caine lester@lsces.co.uk:

The thing is broken

The BLOODY THING IS WORKING PERFECTLY ... what is broken is something
that simply currently necessitates using the resource that has already
been created rather than trying to connect again. The correct response
to someone complaining about it is as with many other things in PHP
simply to explain they are doing it wrong anyway.

This kind of behavior does not belong here in any possible way, and it does
not win you any points in favor. Take the rest of the evening off the
computer if you cannot handle the reality and issues that is present here
in the ext/interbase debate.

regards,

Kalle Sommer Nielsen
kalle@php.net

Now to get back to working out why Nikita's patch does not work in
7.2.16 ...
Obviously because the patch was made for PHP 7.3. Hint: If a
macro/function is not available in 7.2, then look at how it is
implemented in 7.3 and migrate it or see how other functions who do
similar functionality works and port it.

When merging the patch with the older code I was fairly sure that it did
exist already in 7.2 ... but until I can get php-src synced I'm having
to manually scan for this stuff ... at the current rate hg-git will take
24 days so now I need another plan of attack :(

Why are you making it so complicated? php-src has a definition of the
macros, its easy to look up on github.com/php/php-src, just copy this into
the file that uses GC_ADDREF/DELREF above the usage:

#ifndef GC_ADDREF
#define GC_ADDREF(p) (GC_REFCOUNT(p)++)
#endif
#ifndef GC_DELREF
#define GC_DELREF(p) (GC_REFCOUNT(p)--)
#endif

--
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

lør. 23. mar. 2019 kl. 15.22 skrev Lester Caine lester@lsces.co.uk:

Now to get back to working out why Nikita's patch does not work in
7.2.16 ...
Obviously because the patch was made for PHP 7.3. Hint: If a
macro/function is not available in 7.2, then look at how it is
implemented in 7.3 and migrate it or see how other functions who do
similar functionality works and port it.

When merging the patch with the older code I was fairly sure that it did
exist already in 7.2 ... but until I can get php-src synced I'm having
to manually scan for this stuff ... at the current rate hg-git will take
24 days so now I need another plan of attack :(

I don’t know what kind of infrastructure you have going (and frankly I do
not care, even less after what I just read from your part in the past day
or so). But you seem to be the only one with this issue and convoluted
infrastructure, but again irrelevant to the debate currently on going.

Pleased keep these rants of irrelevance off the list.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

This kind of behavior does not belong here in any possible way, and it
does not win you any points in favor. Take the rest of the evening off
the computer if you cannot handle the reality and issues that is present
here in the ext/interbase debate.

It's lunch time here and I've just had a phone call from a client
complaining that their site is down ... just a white screen ...
Actually it was only a small area inside the site and I'd not picked it
up in the several hundred pages that make up the site :( Nothing in fpm7
log to hint at the problem - again - so I AM in something of a bad mood.
Turned out to be part of the upgrade to get these sites working on
PHP7.2/FB3 was missed so suggestions that something I've been using for
20 years does not work does not go down well!

--
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

Den lør. 23. mar. 2019 kl. 15.59 skrev Lester Caine lester@lsces.co.uk:

It's lunch time here and I've just had a phone call from a client
complaining that their site is down ... just a white screen ...
Actually it was only a small area inside the site and I'd not picked it
up in the several hundred pages that make up the site :( Nothing in fpm7
log to hint at the problem - again - so I AM in something of a bad mood.
Turned out to be part of the upgrade to get these sites working on
PHP7.2/FB3 was missed so suggestions that something I've been using for
20 years does not work does not go down well!

Again this is NOT relevant to the thousands of people you are
literally spamming. This stuff belongs on Twitter, your blog or some
other kind of social media, it is NOT relevant to the development of
the PHP runtime, so keep this off the list.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Hi!

"we" are. Like are you kidding me, honestly. Can't you just say
whether it is "we" as in:

• The Firebird community
• The Interbase community
• or a combination?
• Borland?
• Aston Tate?
• The dBase developers?

Also, I wonder could someone from the "we" come forward and sign up as
maintainer for any Firebird/Interbase code? Right now we have:

EXTENSION: interbase
PRIMARY MAINTAINER: Ard Biesheuvel ard@ard.nu (2003 - 2005)

EXTENSION: pdo_firebird
PRIMARY MAINTAINER: Lars Westermann lwe@php.net (2007 - 2007)

That means both extensions are effectively unmaintained for over a
decade. If this does not happen, then continuing to ship it as part of
PHP core distribution is not doing the users any favors.

--
Stas Malyshev
smalyshev@gmail.com

Hi Stas

Den tir. 26. mar. 2019 kl. 00.54 skrev Stanislav Malyshev smalyshev@gmail.com:

That means both extensions are effectively unmaintained for over a
decade. If this does not happen, then continuing to ship it as part of
PHP core distribution is not doing the users any favors.

Please see this RFC I recently posted regarding this subject (and the
relevant internals thread):
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

--
regards,

Kalle Sommer Nielsen
kalle@php.net

That means both extensions are effectively unmaintained for over a
decade. If this does not happen, then continuing to ship it as part of
PHP core distribution is not doing the users any favors.

When critical problems have arisen they have been addressed. The few
current 'bugs' are not critical and the preferred methods of working is
documented. My own attempts at patches in the past have been replaced by
ones from developers who understand the PHP side better than I do :(

News to me is
https://firebirdsql.org/en/news/revival-of-php-driver-development/, but
then many Firebird user groups do not have English as a first language
and just get on with things locally.

--
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

Hi!

News to me is
https://firebirdsql.org/en/news/revival-of-php-driver-development/, but
then many Firebird user groups do not have English as a first language
and just get on with things locally.

Well, this sounds good, but are these people going to develop it outside
PHP project? Or are they going to maintain the existing extension? So
far, it's not clear to me.

--
Stas Malyshev
smalyshev@gmail.com

News to me is
https://firebirdsql.org/en/news/revival-of-php-driver-development/, but
then many Firebird user groups do not have English as a first language
and just get on with things locally.
Well, this sounds good, but are these people going to develop it outside
PHP project? Or are they going to maintain the existing extension? So
far, it's not clear to me.

As I said 'News to me' ... they certainly have not made any contact on
the Firebird php list or responded to any requests to help :( I'm not
totally surprised though as other firebird user groups don't engage
directly with the 'English' groups.

So it looks like I'm going to be stuck on PHP7.3 from now on ...

--
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

News to me is
https://firebirdsql.org/en/news/revival-of-php-driver-development/, but
then many Firebird user groups do not have English as a first language
and just get on with things locally.
Well, this sounds good, but are these people going to develop it outside
PHP project? Or are they going to maintain the existing extension? So
far, it's not clear to me.

As I said 'News to me' ... they certainly have not made any contact on
the Firebird php list or responded to any requests to help :( I'm not
totally surprised though as other firebird user groups don't engage
directly with the 'English' groups.

So it looks like I'm going to be stuck on PHP7.3 from now on ...

I think you misunderstand what is happening here.

Many extensions are "just" in PECL and are still maintained there and kept
updated for newer versions. Distribution maintainers like Remi package all
the PECL extensions for every PHP version. Firebird support will surely be
updated to work with 7.4 and released by distributions. It will just not
be in php-src anymore.

For example, extensions that are not in php-src and are still widely
available in distributions

Memcache
Memcached
APCu
Imagick
Redis

Also Microsoft maintains all its drivres outside of the php-src tree.

--
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

So it looks like I'm going to be stuck on PHP7.3 from now on ...

I think you misunderstand what is happening here.

Many extensions are "just" in PECL and are still maintained there and
kept updated for newer versions. Distribution maintainers like Remi
package all the PECL extensions for every PHP version. Firebird support
will surely be updated to work with 7.4 and released by distributions.
It will just not be in php-src anymore.

Currently building 'interbase' extension has been turned off because
it's failing to pass the changes in master for thread safe operation. I
understand that it needs someone to work on it and I would love to be
able to do that but it's development requirements have moved outside the
area that I can cope with. And many people reliant on it are in the same
boat, just as they would not be able to contribute to writing code for
Firebird itself. While not perfect, what we have currently does it's job
just as PHP5.2 still works on legacy hosting. PDO hopefully will remain
available, but re-writing 20 years worth of code base for that different
way of working has the same problem as finding resources to update the
interbase extension.

--
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

So it looks like I'm going to be stuck on PHP7.3 from now on ...

I think you misunderstand what is happening here.

Many extensions are "just" in PECL and are still maintained there and
kept updated for newer versions. Distribution maintainers like Remi
package all the PECL extensions for every PHP version. Firebird support
will surely be updated to work with 7.4 and released by distributions.
It will just not be in php-src anymore.

Currently building 'interbase' extension has been turned off because
it's failing to pass the changes in master for thread safe operation. I
understand that it needs someone to work on it and I would love to be
able to do that but it's development requirements have moved outside the
area that I can cope with. And many people reliant on it are in the same
boat, just as they would not be able to contribute to writing code for
Firebird itself. While not perfect, what we have currently does it's job
just as PHP5.2 still works on legacy hosting. PDO hopefully will remain
available, but re-writing 20 years worth of code base for that different
way of working has the same problem as finding resources to update the
interbase extension.

PHP needs to support thread safety in all its extensions, but that doesn't
mean its required for PECL extensions. You probably run PHP in NTS mode,
and if the interbase extension supports that, no need to add thread safety
support while in PECL. The problem is that every extension in php-src MUST
support it, because php supports it.

To me it feels you are blowing this issue way out of proportion. Please
believe everyone trying to tell you over and over again that you have
nothing to fear from this unbundling.

--
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

Currently building 'interbase' extension has been turned off because
it's failing to pass the changes in master for thread safe operation. I
understand that it needs someone to work on it and I would love to be
able to do that but it's development requirements have moved outside the
area that I can cope with. And many people reliant on it are in the same
boat, just as they would not be able to contribute to writing code for
Firebird itself. While not perfect, what we have currently does it's job
just as PHP5.2 still works on legacy hosting. PDO hopefully will remain
available, but re-writing 20 years worth of code base for that different
way of working has the same problem as finding resources to update the
interbase extension.

PHP needs to support thread safety in all its extensions, but that doesn't
mean its required for PECL extensions. You probably run PHP in NTS mode,
and if the interbase extension supports that, no need to add thread safety
support while in PECL. The problem is that every extension in php-src MUST
support it, because php supports it.

To me it feels you are blowing this issue way out of proportion. Please
believe everyone trying to tell you over and over again that you have
nothing to fear from this unbundling.

ext/interbase is indeed broken (i.e. uncompilable) in master (not PHP
7.4 though), since PR #3976[1] has been merged. It will certainly be
fixed, if the “Unbundle ext/interbase” RFC[2] will be declined; if it
will be accepted it might never get fixed.

[1] https://github.com/php/php-src/pull/3976
[2] https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

--
Christoph M. Becker

Specifically the events interface is broken all versions of PHP 7:

• In a non-zts build, it executes user code allocated in Thread A in
  Thread B - that's not allowed.
• In a zts build, it makes the same mistake as above, and uses a TSRM API
  to set context which itself has been broken since PHP 7.0.

It so happens that PHP 8 has broken the build, but specifically that part
of the extension has been broken since PHP 7.0.

Cheers
Joe

On Fri, Mar 29, 2019 at 10:20 AM Lester Caine lester@lsces.co.uk
wrote:

Currently building 'interbase' extension has been turned off because
it's failing to pass the changes in master for thread safe operation. I
understand that it needs someone to work on it and I would love to be
able to do that but it's development requirements have moved outside the
area that I can cope with. And many people reliant on it are in the same
boat, just as they would not be able to contribute to writing code for
Firebird itself. While not perfect, what we have currently does it's job
just as PHP5.2 still works on legacy hosting. PDO hopefully will remain
available, but re-writing 20 years worth of code base for that different
way of working has the same problem as finding resources to update the
interbase extension.

PHP needs to support thread safety in all its extensions, but that
doesn't
mean its required for PECL extensions. You probably run PHP in NTS mode,
and if the interbase extension supports that, no need to add thread
safety
support while in PECL. The problem is that every extension in php-src
MUST
support it, because php supports it.

To me it feels you are blowing this issue way out of proportion. Please
believe everyone trying to tell you over and over again that you have
nothing to fear from this unbundling.

ext/interbase is indeed broken (i.e. uncompilable) in master (not PHP
7.4 though), since PR #3976[1] has been merged. It will certainly be
fixed, if the “Unbundle ext/interbase” RFC[2] will be declined; if it
will be accepted it might never get fixed.

[1] https://github.com/php/php-src/pull/3976
[2] https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

--
Christoph M. Becker

Specifically the events interface is broken all versions of PHP 7:

• In a non-zts build, it executes user code allocated in Thread A in
  Thread B - that's not allowed.
• In a zts build, it makes the same mistake as above, and uses a TSRM
  API to set context which itself has been broken since PHP 7.0.

It so happens that PHP 8 has broken the build, but specifically that part
of the extension has been broken since PHP 7.0.

But I am correct to understand the code still compiles and works in NTS
mode, so its not completely broken, only on ZTS.

Cheers
Joe

On Fri, 29 Mar 2019 at 10:40, Christoph M. Becker cmbecker69@gmx.de
wrote:

On Fri, Mar 29, 2019 at 10:20 AM Lester Caine lester@lsces.co.uk
wrote:

Currently building 'interbase' extension has been turned off because
it's failing to pass the changes in master for thread safe operation. I
understand that it needs someone to work on it and I would love to be
able to do that but it's development requirements have moved outside
the
area that I can cope with. And many people reliant on it are in the
same
boat, just as they would not be able to contribute to writing code for
Firebird itself. While not perfect, what we have currently does it's
job
just as PHP5.2 still works on legacy hosting. PDO hopefully will remain
available, but re-writing 20 years worth of code base for that
different
way of working has the same problem as finding resources to update the
interbase extension.

PHP needs to support thread safety in all its extensions, but that
doesn't
mean its required for PECL extensions. You probably run PHP in NTS mode,
and if the interbase extension supports that, no need to add thread
safety
support while in PECL. The problem is that every extension in php-src
MUST
support it, because php supports it.

To me it feels you are blowing this issue way out of proportion. Please
believe everyone trying to tell you over and over again that you have
nothing to fear from this unbundling.

ext/interbase is indeed broken (i.e. uncompilable) in master (not PHP
7.4 though), since PR #3976[1] has been merged. It will certainly be
fixed, if the “Unbundle ext/interbase” RFC[2] will be declined; if it
will be accepted it might never get fixed.

[1] https://github.com/php/php-src/pull/3976
[2] https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

--
Christoph M. Becker

No, it's broken in both modes.

In NTS mode, both the thread that handles events (which illegally calls
user code) and the main thread are executing concurrently, they may both be
calling functions that cause interaction with module globals, which are
obviously shared between threads in NTS mode.

You cannot just start threads and execute user code from anywhere, it's not
safe in NTS mode and is a horrible violation of share nothing in ZTS mode.
It's much more likely to break ZTS mode than NTS, but illegal in both.

Cheers
Joe

Specifically the events interface is broken all versions of PHP 7:

• In a non-zts build, it executes user code allocated in Thread A in
  Thread B - that's not allowed.
• In a zts build, it makes the same mistake as above, and uses a TSRM
  API to set context which itself has been broken since PHP 7.0.

It so happens that PHP 8 has broken the build, but specifically that part
of the extension has been broken since PHP 7.0.

But I am correct to understand the code still compiles and works in NTS
mode, so its not completely broken, only on ZTS.

Cheers
Joe

On Fri, 29 Mar 2019 at 10:40, Christoph M. Becker cmbecker69@gmx.de
wrote:

On Fri, Mar 29, 2019 at 10:20 AM Lester Caine lester@lsces.co.uk
wrote:

Currently building 'interbase' extension has been turned off because
it's failing to pass the changes in master for thread safe operation.
I
understand that it needs someone to work on it and I would love to be
able to do that but it's development requirements have moved outside
the
area that I can cope with. And many people reliant on it are in the
same
boat, just as they would not be able to contribute to writing code for
Firebird itself. While not perfect, what we have currently does it's
job
just as PHP5.2 still works on legacy hosting. PDO hopefully will
remain
available, but re-writing 20 years worth of code base for that
different
way of working has the same problem as finding resources to update the
interbase extension.

PHP needs to support thread safety in all its extensions, but that
doesn't
mean its required for PECL extensions. You probably run PHP in NTS
mode,
and if the interbase extension supports that, no need to add thread
safety
support while in PECL. The problem is that every extension in php-src
MUST
support it, because php supports it.

To me it feels you are blowing this issue way out of proportion. Please
believe everyone trying to tell you over and over again that you have
nothing to fear from this unbundling.

ext/interbase is indeed broken (i.e. uncompilable) in master (not PHP
7.4 though), since PR #3976[1] has been merged. It will certainly be
fixed, if the “Unbundle ext/interbase” RFC[2] will be declined; if it
will be accepted it might never get fixed.

[1] https://github.com/php/php-src/pull/3976
[2] https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

--
Christoph M. Becker

No, it's broken in both modes.

In NTS mode, both the thread that handles events (which illegally calls
user code) and the main thread are executing concurrently, they may both
be calling functions that cause interaction with module globals, which
are obviously shared between threads in NTS mode.

You cannot just start threads and execute user code from anywhere, it's
not safe in NTS mode and is a horrible violation of share nothing in ZTS
mode. It's much more likely to break ZTS mode than NTS, but illegal in both.

The main problem here is that Firebird events are not something one is
likely to use when running a web service? Which is why simply disabling
the events functions would be my own fix in the absence of anybody
coming forward to say they ARE using them. Asynchronous access to third
party services is an area that does require a much more cooperative code
base? Simply asking for a query to run, going off to do other activity,
and returning when the result is available is the sort of activity we
are talking about here?

From the Firebird docs ...

The event notification is asynchronous and takes place at the end of the transaction in which the event was generated. A separate thread is created by TIBEvents to wait on the event notification. When the event occurs it calls the “OnEventAlert” event handler to report which event has been received. Note that the event handler is run in the context of the main thread and hence there is no need to worry about thread synchronisation.

So ibase_wait_event is sitting listening on the same connection that set
the event handler and shares that connection which is where the current
method of working comes from. But I have no idea if this can be changed.
It is the firebird client which is actually holding the connection on
which ibase_wait_event is listening. Using it depends very much on how
PHP handles asynchronous events while I simply want to know that the
read or write I've just done was successful or not ...

--
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