Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 24/03/2019 13:47, Dan Ackroyd wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On Sun, 24 Mar 2019 at 12:32, Rowan Collins wrote: > 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
[PHP-DEV] Re: [RFC] Unbundle ext/interbase
Hi all Den fre. 22. mar. 2019 kl. 15.26 skrev Kalle Sommer Nielsen : > > 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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
Hi Peter Den søn. 24. mar. 2019 kl. 14.39 skrev Peter Kokot : > 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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
Hello, On Fri, 22 Mar 2019 at 14:26, Kalle Sommer Nielsen wrote: > > 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 > ka...@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 24 March 2019 11:33:45 GMT+00:00, Lester Caine wrote: > 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 24/03/2019 10:58, Kalle Sommer Nielsen wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
Den søn. 24. mar. 2019 kl. 10.05 skrev Lester Caine : > > On 24/03/2019 01:42, Kalle Sommer Nielsen wrote: > > 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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 24/03/2019 01:42, Kalle Sommer Nielsen wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
