[RFC] Unbundle ext/interbase

G'day internals

I'd like to start the discussion for the future of the ext/interbase extension:
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

The rationale for pushing this extension out of the core is mentioned
in the RFC.

Unless there is any serious issues raised here, then I will put this
into voting on Monday 8th of April, noon EET (which is a good two and
a half weeks away). The intended voting period is set for 2 weeks,
meaning if voting proceeds, the pools will be closed around Monday
22th of April, noon EET.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Morning Kalle,

Seems like a reasonable plan, +1

Cheers
Joe

G'day internals

I'd like to start the discussion for the future of the ext/interbase
extension:
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

The rationale for pushing this extension out of the core is mentioned
in the RFC.

Unless there is any serious issues raised here, then I will put this
into voting on Monday 8th of April, noon EET (which is a good two and
a half weeks away). The intended voting period is set for 2 weeks,
meaning if voting proceeds, the pools will be closed around Monday
22th of April, noon EET.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

G'day internals

I'd like to start the discussion for the future of the ext/interbase extension:
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

The rationale for pushing this extension out of the core is mentioned
in the RFC.

Unless there is any serious issues raised here, then I will put this
into voting on Monday 8th of April, noon EET (which is a good two and
a half weeks away). The intended voting period is set for 2 weeks,
meaning if voting proceeds, the pools will be closed around Monday
22th of April, noon EET.

It is not that we don't want to stand up and maintain it, it has been
impossible in recent years to get a handle on just what needs to be done
TO maintain it. The PDO extension is in a much worse state than the main
interbase one but both of them do their jobs as well as they can given
that in the case of PDO it can't handle the cross database transactions,
something that the main extension does quite happily.

Personally I've been wasting time recently trying to keep alive sites
that are using MySQL and the main problem with MySQL is the one thing
that Firebird does nicely. Backup just runs as a secondary cron job
independent of PHP while MySQL is reliant on PHP and current backups on
some wordpress powered sites are failing because they run out of time or
memory. I've never had a problem with loosing data with Firebird while
I've had recover MySQL situations a few times in the last year!

So all we are asking for is HELP with the code changes that result from
changes to the PHP API to keep this available.

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

G'day Lester

Den fre. 22. mar. 2019 kl. 16.10 skrev Lester Caine lester@lsces.co.uk:

It is not that we don't want to stand up and maintain it, it has been
impossible in recent years to get a handle on just what needs to be done
TO maintain it. The PDO extension is in a much worse state than the main
interbase one but both of them do their jobs as well as they can given
that in the case of PDO it can't handle the cross database transactions,
something that the main extension does quite happily.

Like the previous 2-3 times we have had this topic going about
removing the InterBase extension, you have referred to "we" (which I
suppose is the PHP community as a whole), however time over and time
again, no one has stepped up who has been able to maintain it. I
thought about the PDO_Firebird extension too for removal, but I wanted
to give the few possible PHP Firebird users a chance to evaluate the
situation

What do I mean by this? I mean that from a Core perspective (which I
have explained before to you personally a few years ago), but to
re-iterate: An extension in the Core that is not maintained, poses a
risk of security and maintenance required to keep the extension to a
level of quality that you (you as in the PHP community) deserve can
therefore not be up to par. On top of that, it is a burden on us Core
Developers that we cannot do anything to fix it.

Personally I've been wasting time recently trying to keep alive sites
that are using MySQL and the main problem with MySQL is the one thing
that Firebird does nicely. Backup just runs as a secondary cron job
independent of PHP while MySQL is reliant on PHP and current backups on
some wordpress powered sites are failing because they run out of time or
memory. I've never had a problem with loosing data with Firebird while
I've had recover MySQL situations a few times in the last year!

That sounds like a bug in MySQL, which you should probably report to
them or look at your configuration.

So all we are asking for is HELP with the code changes that result from
changes to the PHP API to keep this available.

We asked for help in the past, many times in the fact if you search
the archives (and you have taken apart of the conversation every
single time), nothing has happened, therefore it is time to move past
this. The extension will put in a repository at PECL, however it is
unlike to retrieve further improvements or fixes from there unless
someone actually steps up to take over it.

We have done what we can to try call for help to keep this extension
for as long as possible, but we can only do so much for so long.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

it has been impossible in recent years to get a handle
on just what needs to be done TO maintain it.

Yes, figuring out what needs to be done takes more time that writing the
code. Did you not know this?

This is what takes up most of my time as the maintainer of the Imagick
extension. I hardly write any code for it, instead I spend a lot of time
trying to figure out:

• what has changed upstream? Do I need to support that change?
• is this bug report valid? which involves spending time trying to recreate
  it.
• how is a feature of it that I've never used myself meant to work?
• what needs more documentation? And then writing that documentation.

All of that is tediously boring to me, and yet I still do it because I care
just enough to avoid the extension from being considered abandoned.

We've had this discussion about the interbase extension multiple times.
Each time people have said they will step up to maintain it. But apparently
each time no-one actually cares enough to commit the time to be up-to-speed
and maintain the extension.

So all we are asking for is

Who is we in this sentence?

Is it end-users who claim that it's a vital part of their business, but
haven't actually contributed enough of their time to maintain it?

Or is it the billion dollar company that bought Interbase (
https://www.ideracorp.com/brands), and has recently bought Travis CI, and
yet doesn't want to hire someone to maintain the extension?

In either case, you are asking people who do not use a piece of software to
donate their own time maintaining it.

btw please do not cross post to multiple groups. If you want to make the
firebird developers aware of this proposal you should do separately from
your emails to PHP internals.

cheers
Dan
Ack

G'day internals

I'd like to start the discussion for the future of the ext/interbase
extension:
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

The rationale for pushing this extension out of the core is mentioned
in the RFC.

Unless there is any serious issues raised here, then I will put this
into voting on Monday 8th of April, noon EET (which is a good two and
a half weeks away). The intended voting period is set for 2 weeks,
meaning if voting proceeds, the pools will be closed around Monday
22th of April, noon EET.

It is not that we don't want to stand up and maintain it, it has been
impossible in recent years to get a handle on just what needs to be done
TO maintain it. The PDO extension is in a much worse state than the main
interbase one but both of them do their jobs as well as they can given
that in the case of PDO it can't handle the cross database transactions,
something that the main extension does quite happily.

Personally I've been wasting time recently trying to keep alive sites
that are using MySQL and the main problem with MySQL is the one thing
that Firebird does nicely. Backup just runs as a secondary cron job
independent of PHP while MySQL is reliant on PHP and current backups on
some wordpress powered sites are failing because they run out of time or
memory. I've never had a problem with loosing data with Firebird while
I've had recover MySQL situations a few times in the last year!

So all we are asking for is HELP with the code changes that result from
changes to the PHP API to keep this available.

Hi Lester,

I've created a patch for https://bugs.php.net/bug.php?id=72175 (last
comment), which seems to be the biggest open problem in the interbase
extension. I'd appreciate it if you or someone else who uses firebird could
test this.

Nikita

I've created a patch forhttps://bugs.php.net/bug.php?id=72175 (last
comment), which seems to be the biggest open problem in the interbase
extension. I'd appreciate it if you or someone else who uses firebird could
test this.

Nikita

Am I jumping the gun a bit? I've got 7.2.16 configured so I can compile
it myself. It's throwing a warning on compile
./ibase.h:761:28: note: expected ‘ISC_UCHAR ** {aka unsigned char **}’
but argument is of type ‘char ’
ISC_LONG ISC_EXPORT_VARARG isc_event_block(ISC_UCHAR, but the
compiled copy is clearing my ibtest suite.

I've ported your patch to the 7.2.16 copies of the files but this is
throwing a different warning
"implicit declaration of function ‘GC_ADDREF’;" and GC_DELREF
GC_ADDREF certainly exists in the file already but not GC_DELREF so am I
missing something that will stop me making this work on 7.2.16?

It is at least running - http://smallbrook.co.uk:800/phpinfo.php but I
need to add something to test this problem as my framework only uses a
singleton connection ... http://smallbrook.co.uk:800 needs a login, but
the database searches are running fine.

I'm still waiting on mercurial syncing with git but hopefully in the
morning I'll be able to cross check changes in the files over time.

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

I've created a patch forhttps://bugs.php.net/bug.php?id=72175 (last
comment), which seems to be the biggest open problem in the interbase
extension. I'd appreciate it if you or someone else who uses firebird could
test this.

OK now got a test framework on the development machine where I can check
things out. As expected, starting two connections to two different
databases just works and simply copying $link to $link1 works as one
would expect. But trying to create a second connection to the same
database is currently giving me a crash and 'undefined symbol:
GC_ADDREF' So I need to tidy up the patch to work with 7.2.16 :(

The other part of the jigsaw is working out the significance of the
'default_link' in the code. And I'm taking this back to the firebird
developers to check something out. As far as I am aware the firebird
CLIENT will reuse an active connection to the database, but if one
creates several connections in PHP and a couple end up linking to the
same database where does a default one come into the picture. I think
the code is basing decisions on the first connection made? Rather than
the poll of active connections ...

As stated in the bug report, there is no need to reconnect to the same
database, but there will be a default transaction for the connection
which requires explicit transactions to be handled and this may be why
there is thought to be a need to open new connections when one simply
manages extra transactions on the same link. Working of a singleton link
just works and so in that case the bug is irrelevant rather than a show
stopper.

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

G'day internals

To everyone reading this thread please note:

Although people are free to discuss RFCs amongst themselves off-list, it is
not appropriate behaviour to contact people discussing an RFC on this list
through other communication channels.

Any communication about the topic that you want to send to someone in this
thread should be sent via the PHP internals list.

cheers
Dan
Ack

• unless of course you know the person yourself off-list.

I'd like to start the discussion for the future of the ext/interbase extension:
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

Currently I am seeing 6 open bugs against ext/interbase going back to
2009 ...
48447 - 2009
The oldest bug relates I think to threading and I think the problem here
is trying to use the same connection opened in one thread in the child
thread. Close the connection then fork and I am presuming it will work,
but I don't have pcntl loaded in production and had to add it to the
test setup ... but don't know what I would use it for, but it may be
appropriate to use with Firebird's events interface.
62300 - 2012
Tomorrows job ... have the files downloaded now, but I don't recognise
the problem as we use null all the time to trigger the database
generator code.
71650 - 2016
We do have it documented
http://www.janus-software.com/fbmanual/man.php?book=php and it may be
necessary to separate it out from the interbase extension to cope with
Firebird 4 which adds new data types!
72175 - 2016
The patch nikita has proposed works nicely now I've got it running on
7.2.16 ... the WAY duplicate connections to the same database are
handled may be part of the problem with Bug 48447 ...
74076 - 2017
The reported bug is not repeatable, but using the wrong resource id will
trigger a seg fault. Not sure if it's possible to detect the mistake and
error instead.
74104 - 2017
Again not able to duplicate, but it looks like it's a matter of
replacing strptime which should be something I can address in isolation.
Getting dates in is the biggest problem everywhere.

So is there anything else which is required to bring the extension up to
date? There is nothing above that prevents the extension doing it's job
for the vast majority of users and even the suggestion that it is
unusable due to Bug 72175 does not stand up to scrutiny and can now be
fixed in 7.3 and 7.2 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

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

So is there anything else which is required to bring the extension up to
date? There is nothing above that prevents the extension doing it's job
for the vast majority of users and even the suggestion that it is
unusable due to Bug 72175 does not stand up to scrutiny and can now be
fixed in 7.3 and 7.2 anyway ...

I updated the RFC with a section earlier to list some of the issues
the extension currently has. Like Joe said in the other thread, it
does bad bad things in ZTS among some of the serious issues. Even if
these things are fixed, we do not have a guarantee to have someone who
is capable of dealing with the issues at hand in the future, nor do I
see fixing bug#72175 as a reason to halt this RFC.

Like I have expressed to people who has mailed me off list (which is
inappropriate) that the extension can be taken over by anyone who
wants to from the relevant community, it just will not be distributed
by default with PHP. In fact if the extension is released on PECL, it
gives the relevant community more freedom to deal with the extension
as they deem fit and does not have the strict requirements as
extensions in the Core has. Sources and binaries are still available
with the PECL interface.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

I updated the RFC with a section earlier to list some of the issues
the extension currently has.

Thread safety is one area where the way the extension was structured
originally may now be wrong, but the main problem with multiple
connections is confined completely to multiple connections to a single
database. In particular the 'default link' is actually the default
transaction handle and additional links are simply multiple transactions
on the one connection which I think is where some of the confusion has
come from :( A more established Firebird user would simply start a new
transaction, while a newbie may try to start a new connection. And in
the past the extension has hidden that and quietly picked up the
existing one ...

"A small subset of field types are supported, anything else crashes"
This is news to me ... is there any bug report to back it up? All the
current data types provided by Firebird are working in the extension,
but you may well be right that we may be better off cloning the existing
code and building a Firebird only port going forward. The concern is the
same one we had with windows in the past, where adding extra extensions
does not always work reliably ... one has to provide a wrapped package
with all the edge cases addressed. But all my use in production is using
ADOdb to wrap the database SQL problems ...

--
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 extension can be taken over by anyone who
wants to from the relevant community, it just will not be distributed
by default with PHP. In fact if the extension is released on PECL, it
gives the relevant community more freedom to deal with the extension
as they deem fit and does not have the strict requirements as
extensions in the Core has. Sources and binaries are still available
with the PECL interface.

It's probably worth noting the example of Microsoft SQL Server here: the previous PHP extensions were dropped from the core in 7.0, and Microsoft now manages an open-source, cross-platform extension, and is able to release it as often as they want, and bring in features and bug fixes to encourage its use: https://github.com/Microsoft/msphpsql

For an extension connecting to any actively developed third-party system, this is probably actually the best model, with PHP Internals experts providing advice where necessary, and third-party experts tracking innovations in the particular system.

Regards,

--
Rowan Collins
[IMSoP]

Hi Lester

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

Thread safety is one area where the way the extension was structured
originally may now be wrong, but the main problem with multiple
connections is confined completely to multiple connections to a single
database. In particular the 'default link' is actually the default
transaction handle and additional links are simply multiple transactions
on the one connection which I think is where some of the confusion has
come from :( A more established Firebird user would simply start a new
transaction, while a newbie may try to start a new connection. And in
the past the extension has hidden that and quietly picked up the
existing one ...

The default link should not be related to thread safety, it should be
related to the design of how database extensions used to be working.
The design was as follows (using the old ext/mysql as an example
here).

mysql_connect('localhost', 'user', 'password');
mysql_select_db('test'); // The last created connection is implicitly added here

This is the "default" link. This is some magical behavior which made
the API very easy to use, however it also created some hard to debug
situations with multiple connections. ext/interbase seems to still go
by this design which is most likely the reason to why some of the
weirdness of the extension behavior after the blind updates to
somewhat work on PHP7.

Regarding the connection and fork(), is this a problem in other
database extensions, if not, then it may be worth it for whoever ends
up picking up the extension to look at how others do this. The design
of this extension is fairly old and prone to unforeseen errors.

"A small subset of field types are supported, anything else crashes"
This is news to me ... is there any bug report to back it up? All the
current data types provided by Firebird are working in the extension,
but you may well be right that we may be better off cloning the existing
code and building a Firebird only port going forward. The concern is the
same one we had with windows in the past, where adding extra extensions
does not always work reliably ... one has to provide a wrapped package
with all the edge cases addressed. But all my use in production is using
ADOdb to wrap the database SQL problems ...

I count 13 open bugs[1] in regards to ext/interbase thats been
reported, there are probably a ton more. Bug#74946 talks about a crash
with a type, leading me to believe that if one type can crash, then
more are very likely too.

[1] https://bugs.php.net/search.php?cmd=display&bug_type=All&status=Open&package_name%5B%5D=InterBase+related&by=Any&limit=30

regards,

Kalle Sommer Nielsen
kalle@php.net

(Neely forgot to fix reply address!)

mysql_connect('localhost', 'user', 'password');
mysql_select_db('test'); // The last created connection is implicitly added here

This situation never exists in Firebird or Interbase. The ONLY way to
connect is to a database, you can not connect to the server without
using a database in the connection string. Each database is it's own
file or set of files if spread across multiple disks. There is no way of
asking a server what databases are available, you have to know
beforehand. Although some newcomers call it a bug it's an original
design feature.

I'll add BOOLEAN to https://phpsurgery.org/tests/ibtest.php tomorrow,
but there are bugs in your link that don't show in the link I have been
using :( But some of them are not bugs ...

--
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 søn. 24. mar. 2019 kl. 03.11 skrev Lester Caine lester@lsces.co.uk:

(Neely forgot to fix reply address!)

mysql_connect('localhost', 'user', 'password');
mysql_select_db('test'); // The last created connection is implicitly added here

This situation never exists in Firebird or Interbase. The ONLY way to
connect is to a database, you can not connect to the server without
using a database in the connection string. Each database is it's own
file or set of files if spread across multiple disks. There is no way of
asking a server what databases are available, you have to know
beforehand. Although some newcomers call it a bug it's an original
design feature.

Really Lester, really. It was a pseudo example, do I really need to be
EXPLICIT and spell everything out very specifically for you?

ibase_connect('localhost:/path/to/some/db.gdb', 'user', 'password');
ibase_query('UPDATE a_table SET a_column = 1'); // The last created
connection is implicitly added here

What happens here is that PHP retain the last connection created by
ibase_connect() and uses it as a "default" link, meaning you do not
pass a connection resource to ibase_query() afterwards.

Compare the example to:

$link = ibase_connect('localhost:/path/to/some/db.gdb', 'user', 'password');
ibase_query($link, 'UPDATE a_table SET a_column = 1'); // Explicit, as
the first parameter is a connection resource

Besides this, it has further magic behavior if the multiple
connections are created with the same credentials as one in the same
process, I'm not sure if this is fixed with Nikita's patch.

I'll add BOOLEAN to https://phpsurgery.org/tests/ibtest.php tomorrow,
but there are bugs in your link that don't show in the link I have been
using :( But some of them are not bugs ...

Then use the link from the statistics page on bugs.php.net? There is
probably a fair few for PDO_Firebird too you can find on that page

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Besides this, it has further magic behavior if the multiple
connections are created with the same credentials as one in the same
process, I'm not sure if this is fixed with Nikita's patch.

But that IS the point here ... In fact many people using Firebird with
PHP use it in 'embedded mode', where the client is actually the server
process and explicitly blocks a second physical connection! The default
$link is the initial default transaction and ibase_trans creates
additional links encapsulating additional transactions on the database
if work flow requires. The difficulty and one that PDO can never support
is that a transaction CAN encapsulate two or more different physical
connections and it is this which dictates that operations need an
explicate '$link_or_trans_identifier'. Personally I use $conn and
$transnnn explicitly to keep track of things ... but if you only open a
single physical connection and don't add transactions then the
'default_link' is the only packet of workflow.

ibase_connect specifically says
"In case a second call is made to ibase_connect() with the same
arguments, no new link will be established, but instead, the link
identifier of the already opened link will be returned. The link to the
server will be closed as soon as the execution of the script ends,
unless it's closed earlier by explicitly calling ibase_close(). " It was
this action that as broken around 7.0.3 ... and it's probably totally
incompatible with 'thread safe'? But the firebird client can handle
multiple calling processes - and persist connections - so the 'bug' is
probably in how PHP and Firebird interact in a new world? We are still
using a 20+ year old model.

For a simple single transaction packet of work one opens a connection
does the work and if the activity crashes it is rolled back otherwise it
autocommits when finished. Yes this is magic behaviour but it's the same
magic behaviour that it has always done even on C and Delphi platforms
and for the vast majority of PHP processes it's all that is needed? It's
just not politically correct today?

--
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 søn. 24. mar. 2019 kl. 10.05 skrev Lester Caine lester@lsces.co.uk:

Besides this, it has further magic behavior if the multiple
connections are created with the same credentials as one in the same
process, I'm not sure if this is fixed with Nikita's patch.

But that IS the point here ... In fact many people using Firebird with
PHP use it in 'embedded mode', where the client is actually the server
process and explicitly blocks a second physical connection! The default
$link is the initial default transaction and ibase_trans creates
additional links encapsulating additional transactions on the database
if work flow requires. The difficulty and one that PDO can never support
is that a transaction CAN encapsulate two or more different physical
connections and it is this which dictates that operations need an
explicate '$link_or_trans_identifier'. Personally I use $conn and
$transnnn explicitly to keep track of things ... but if you only open a
single physical connection and don't add transactions then the
'default_link' is the only packet of workflow.

ibase_connect specifically says
"In case a second call is made to ibase_connect() with the same
arguments, no new link will be established, but instead, the link
identifier of the already opened link will be returned. The link to the
server will be closed as soon as the execution of the script ends,
unless it's closed earlier by explicitly calling ibase_close(). " It was
this action that as broken around 7.0.3 ... and it's probably totally
incompatible with 'thread safe'? But the firebird client can handle
multiple calling processes - and persist connections - so the 'bug' is
probably in how PHP and Firebird interact in a new world? We are still
using a 20+ year old model.

For a simple single transaction packet of work one opens a connection
does the work and if the activity crashes it is rolled back otherwise it
autocommits when finished. Yes this is magic behaviour but it's the same
magic behaviour that it has always done even on C and Delphi platforms
and for the vast majority of PHP processes it's all that is needed? It's
just not politically correct today?

Your objection to the deprecation and removal of ext/interbase has
been noted, and will be recorded at vote time. I would ask that
discussion about how ext/interbase works or should work, or how it
worked twenty years ago, or how it works in Delphi is conducted
elsewhere, as this RFC is around the removal of it. Thank you

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Your objection to the deprecation and removal of ext/interbase has
been noted, and will be recorded at vote time.

I have no doubt the rfc will go through, my problem then is that PHP7.4
essentially becomes a nogo zone because there is no way to remove the
deprecation warnings and hiding them also hides the deprecation messages
that can and do need addressing :( Despite the politically correct
action of hiding all errors/warnings on production machines, I've always
displayed them and I'm not about to change that habit as an error
message is much better than a white screen any day. Although I still get
white screens as 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

problem then is that PHP7.4
essentially becomes a nogo zone because there is no way to remove the
deprecation warnings

Presumably the PECL extension, with no deprecation warnings, could be set up straight away, and builds offered for PHP 7.4. That way, the deprecation notices are immediately actionable, and the new home of the extension gets more publicity.

Regards,

--
Rowan Collins
[IMSoP]

Hello,

G'day internals

I'd like to start the discussion for the future of the ext/interbase extension:
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

The rationale for pushing this extension out of the core is mentioned
in the RFC.

Unless there is any serious issues raised here, then I will put this
into voting on Monday 8th of April, noon EET (which is a good two and
a half weeks away). The intended voting period is set for 2 weeks,
meaning if voting proceeds, the pools will be closed around Monday
22th of April, noon EET.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

--

I'm all in for helping out here with both users using this and
maintainers that need to worry about if this extension is even working
ok. However, just one quick thought. The deprecation usually means
that some functionality will cease to exist. And users usually expect
and consider removing deprecated usage from their code and move to
something else. Not that they will have an option to install it over
PECL in PHP 8.0... Is this ok approach for this case? Because with
this approach PHP is also saying quietly that PECL is a museum for
extensions and not a place for developing them further. I might be
completely wrong here though...

Peter Kokot

Hi Peter

Den søn. 24. mar. 2019 kl. 14.39 skrev Peter Kokot peterkokot@gmail.com:

I'm all in for helping out here with both users using this and
maintainers that need to worry about if this extension is even working
ok. However, just one quick thought. The deprecation usually means
that some functionality will cease to exist. And users usually expect
and consider removing deprecated usage from their code and move to
something else. Not that they will have an option to install it over
PECL in PHP 8.0... Is this ok approach for this case? Because with
this approach PHP is also saying quietly that PECL is a museum for
extensions and not a place for developing them further. I might be
completely wrong here though...

I opted for the deprecation warning as the functionality will
effectively cease to exist in php-src, we have done similar things to
other extensions (recently ext/wddx) or even ext/mysql (which did have
the ext/mysqli and ext/pdo_mysql) as alternatives, similar
ext/interbase have the ext/pdo_firebird alternative.

I see the following options to go about this extension:

1. Add a deprecation warning as the functionality will effective cease
   to exist in php-src. We don't know if this extension will be taken
   over if it ends up in PECL, so this is the safe bet, which is why I
   opted for this initially in the RFC
2. Silently remove it already in 7.4, this is also a very viable
   option, but it does not give the users to think about alternatives, We
   did this for some extension in 5.6 -> 7.0, like ext/mssql. If we go
   with this option, it means that there is no warnings and that whoever
   picks up the extension (if any) can give them a warning free
   environment.

I can amend the RFC to have these voting choices in mind if it is
preferable, similar to ext/wddx.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Hi all

Den fre. 22. mar. 2019 kl. 15.26 skrev Kalle Sommer Nielsen kalle@php.net:

G'day internals

I'd like to start the discussion for the future of the ext/interbase extension:
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

I have updated the RFC to contain 4 proposed voting choices in form of
a secondary vote to decide on the strategy, these are:

• Move to PECL in 7.4
• Remove in 7.4
• Deprecate in 7.4, Move to PECL in 8.0
• Deprecate in 7.4, Remove in 8.0

This strategy will only be chosen if the primary vote passes.

This is based on recent feedback and again, if no serious issues comes
up, the RFC will go to voting on 8th of April, noon EET as the
original intention, which is a good 15 days away.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Presumably the PECL extension... the new home of the extension gets more
publicity.

It's worth noting that even after the extension is moved from core to it's
own repository, most people using it on Debian or Centos/Redhat/Fedora
won't notice any difference.

The maintainers of those distributions already package the ibase/firebird
extension separately to PHP core, and where the code for that extension
comes from won't make any difference to end-users.

The only difference the RFC will make to those people is that it will
remove the false promise that the code is currently maintained by PHP core
people.

cheers
Dan

It's worth noting that even after the extension is moved from core to it's
own repository, most people using it on Debian or Centos/Redhat/Fedora
won't notice any difference.

On one hand this is correct but the reason I got stung with a move to
PHP7.2 before I was ready was because SUSE pulled the 7.0 repo despite
7.0 being the LTS version on that base distribution. I needed to rebuild
a machine, but the key component was not available ... and in hindsight
I should probably have pulled a copy of 7.0 from php.net rather than
taking the 7.2 replacement.

On one hand we get good support from the various distributions, but
being able to dovetail that in with the main project can be essential at
times! Being ALLOWED to select when we have completed upgrading our end
to be compatible is rather important these days, given the much faster
upgrade cycles, but not always easy where distros 'keep up to date'
automatically :( And even more difficult when they stick with an older
version when you need the updated one :(

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

I see the following options to go about this extension:

1. Add a deprecation warning as the functionality will effective cease
   to exist in php-src. We don't know if this extension will be taken

As an end user (in this case, PHP developer that needs to use Firebase
functionality), I couldn't care less where the source code that compiles
to the extension lives - php-src or pecl. So warning me about that is
not very useful for me. If it gets moved to pecl, I'll discover it from
UPGRADING note, amend my install list to fetch the pecl package and that
should be the end of the matter for me.

In my opinion, deprecation warnings should be used for functionality
that the used needs to remove from the code. That's not what we're doing
here - and that's not realistic for us to ask people to do, since it's
not likely they'd just drop their DB backend. They'd use PECL package
instead, or older version. The proper place to warn about this is the
release notes (UPGRADING), not runtime deprecation warnings.

--
Stas Malyshev
smalyshev@gmail.com

In my opinion, deprecation warnings should be used for functionality
that the used needs to remove from the code. That's not what we're doing
here -

That's a good point.

Another thing that probably needs consideration is that if/when
someone from the Firebird community steps up to maintain the
extension, at some point it would probably be appropriate to fork the
extension to be named Firebird, rather than ibase, as it appears that
Interbase and Firebird have forked and are no longer fully compatible
with each other:

https://ib-aid.com/en/articles/differences-between-firebird-and-interbase/

InterBase was created in 1985: it was the first commercial multi-versioning database. In the end
of 1999, Borland decided to close InterBase development and published its source codes under
InterBase Public License. This code was copied (it is permitted by the license), and Firebird
was born – from the version 1.0 Firebird is a production-ready database, based on
previous decades of InterBase development.

....

Since then, the difference between Firebird and InterBase became bigger.

It would be pretty reasonable for a maintainer from the Firebird
community to maintain the extension for Firebird compatibility, rather
than maintaining it to be Interbase compatible. But having it still be
named after Interbase would be quite confusing.

The exact details of that can be discussed after the vote, and when
someone applies to maintain it.

cheers
Dan
Ack

Den fre. 22. mar. 2019 kl. 15.26 skrev Kalle Sommer Nielsen kalle@php.net:

https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

Given the feedback, the RFC only targets the ext/interbase extension
to be bundled and moved to PECL.

Behind the scenes, the german firebird community has reached out to me
in private with what seems to be their intention to take over the
extension, but without any further feedback from them (nor internals
participaction), even with the help of Joe and Sebastian to write a
mail in german to explain the reasoning and what an extension in PECL
may mean for them.

Given this, the RFC will go into voting on noon monday EET, April 8th
as previously planned.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Den fre. 22. mar. 2019 kl. 15.26 skrev Kalle Sommer Nielsen <kalle@php.net

:
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

Given the feedback, the RFC only targets the ext/interbase extension
to be bundled and moved to PECL.

Behind the scenes, the german firebird community has reached out to me
in private with what seems to be their intention to take over the
extension, but without any further feedback from them (nor internals
participaction), even with the help of Joe and Sebastian to write a
mail in german to explain the reasoning and what an extension in PECL
may mean for them.

You can add me to the loop and I can explain them the process, in German or
have a call with them if needed.

Given this, the RFC will go into voting on noon monday EET, April 8th
as previously planned.

thanks:)

--
regards,

Kalle Sommer Nielsen
kalle@php.net