Everything

php

Firebird - Who are WE ...

php.internals

Lester Caine

7 years ago

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

Kalle Sommer Nielsen

7 years ago

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

Lester Caine

7 years ago

On 23/03/2019 12:05, Kalle Sommer Nielsen wrote:

> 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

Kalle Sommer Nielsen

7 years ago

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

Lester Caine

7 years ago

On 23/03/2019 12:46, Kalle Sommer Nielsen wrote:

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

Benjamin Eberlei

7 years ago

On Sat, Mar 23, 2019 at 2:22 PM Lester Caine <lester@lsces.co.uk> wrote:

> On 23/03/2019 12:46, Kalle Sommer Nielsen wrote:
> >> 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

Kalle Sommer Nielsen

7 years ago

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

> On 23/03/2019 12:46, Kalle Sommer Nielsen wrote:
> >> 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

Joe Watkins

7 years ago

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

On Sat, 23 Mar 2019, 13:36 Lester Caine, <lester@lsces.co.uk> wrote:

Lester Caine

7 years ago

On 23/03/2019 12:47, Joe Watkins wrote:

> 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

Joe Watkins

7 years ago

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.

On Sat, 23 Mar 2019, 14:16 Lester Caine, <lester@lsces.co.uk> wrote:

Kalle Sommer Nielsen

7 years ago

Lester

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

> On 23/03/2019 12:47, Joe Watkins wrote:
> > 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

Lester Caine

7 years ago

On 23/03/2019 13:30, Kalle Sommer Nielsen wrote:

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

Kalle Sommer Nielsen

7 years ago

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

Stas Malyshev

7 years ago

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

Kalle Sommer Nielsen

7 years ago

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

Lester Caine

7 years ago

On 25/03/2019 22:54, Stanislav Malyshev wrote:

> 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

Stas Malyshev

7 years ago

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

Lester Caine

7 years ago

On 29/03/2019 06:05, Stanislav Malyshev wrote:

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

Benjamin Eberlei

7 years ago

On Fri, Mar 29, 2019 at 9:41 AM Lester Caine <lester@lsces.co.uk> wrote:

> On 29/03/2019 06:05, Stanislav Malyshev wrote:
> >> 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

7 years ago

On 29/03/2019 08:50, Benjamin Eberlei wrote:

>     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

Benjamin Eberlei

7 years ago

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

> On 29/03/2019 08:50, Benjamin Eberlei wrote:
> >     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.

Christoph Becker

7 years ago

On 29.03.2019 at 10:29, Benjamin Eberlei 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