# [RFC][DISCUSSION] Removal of dead SAPIs and extensions - Thread: https://externals.io/message/80838 - Original archive: https://news-web.php.net/php.internals/80838 - Started by Anatol Belski on 2015-01-19T17:07:22+00:00 - Messages: 13 - RFC: Removal of dead SAPIs and extensions (Implemented (PHP 7.0)) — https://externals.io/rfc/removal_of_dead_sapis_and_exts.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #80838 — Anatol Belski — 2015-01-19T17:07:22+00:00 URL: https://externals.io/message/80838#80838 Hi, I think the research on https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts is now far enough to be discussed. So far I only could not test sapi/nsapi because it needs a SunOs/IPlanet. But independent from that, it'd make sense someone to recheck my perceptions, or just the areas one is interested in. Also hereby I'm calling the authors/maintainers of the corresponding units to give the info about their intentions. Lets think about it, anyway. Maybe I've missed some extension yet, then that were a chance to add it to the RFC. Thanks Anatol --- ## #80853 — Dmitry Stogov — 2015-01-20T05:08:49+00:00 URL: https://externals.io/message/80838#80853 · In reply to: #80838 Hi Anatol, Despite of this, we also have few extensions not converted to PHP7 yet - https://wiki.php.net/phpng#unsupported_extensions_not_converted_yet 3 of them related to MSSQL, 2 to Oracle and one to Interbase. the last one is partially converted (may be compiled), but it's so ugly, so it won't work without serious redesign (I'm not sure how it worked in php-5). Thanks. Dmitry. On Mon, Jan 19, 2015 at 8:07 PM, Anatol Belski wrote: > Hi, > > I think the research on > https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts is now far enough > to be discussed. > > So far I only could not test sapi/nsapi because it needs a SunOs/IPlanet. > But independent from that, it'd make sense someone to recheck my > perceptions, or just the areas one is interested in. > > Also hereby I'm calling the authors/maintainers of the corresponding units > to give the info about their intentions. > > Lets think about it, anyway. Maybe I've missed some extension yet, then > that were a chance to add it to the RFC. > > Thanks > > Anatol --- ## #80855 — Pierre Joye — 2015-01-20T05:26:34+00:00 URL: https://externals.io/message/80838#80855 · In reply to: #80853 > Hi Anatol, > > Despite of this, we also have few extensions not converted to PHP7 yet - > https://wiki.php.net/phpng#unsupported_extensions_not_converted_yet > > 3 of them related to MSSQL, 2 to Oracle and one to Interbase. the last one > is partially converted (may be compiled), but it's so ugly, so it won't work > without serious redesign (I'm not sure how it worked in php-5). Seriously I would also like to see all three in pecl. I am not saying that they are not used nor maintained but a more flexible releases and leave more options to the maintainer(s) could actually help. The main problem here is the barrier to get a dev environment up and working, quite high, especially for the 1st two. Interbase is easier but is a niche server, so any kind of fixes or changes tightly related to how this DB works require more than the usual suspects like pgsql, mysql or sqlite. I also do not like to use pecl as a cemetery for dead cows. After this RFC, if some choices are actually accepted, let discuss how to deal with that, from a pecl.php.net point of view. I would rather have them marked dead and to do not appear in default search, a big warning on install should be displayed as well (that's something I can take of if desired). Maybe change the RFC title to reflect both kind of moves and them to the list. Cheers, Pierre --- ## #80856 — Pierre Joye — 2015-01-20T05:27:43+00:00 URL: https://externals.io/message/80838#80856 · In reply to: #80855 > Seriously I would also like to see all three in pecl. I am not saying > that they are not used nor maintained but a more flexible releases and > leave more options to the maintainer(s) could actually help. The main > problem here is the barrier to get a dev environment up and working, > quite high, especially for the 1st two. +sybase > Interbase is easier but is a > niche server, so any kind of fixes or changes tightly related to how > this DB works require more than the usual suspects like pgsql, mysql > or sqlite. --- ## #80866 — Anatol Belski — 2015-01-20T09:22:46+00:00 URL: https://externals.io/message/80838#80866 · In reply to: #80853 Hi Dmitry, > Hi Anatol, > > > Despite of this, we also have few extensions not converted to PHP7 yet - > https://wiki.php.net/phpng#unsupported_extensions_not_converted_yet > > > 3 of them related to MSSQL, 2 to Oracle and one to Interbase. the last > one is partially converted (may be compiled), but it's so ugly, so it > won't work without serious redesign (I'm not sure how it worked in php-5). > I'm going to rename and update the RFC to handle these cases as well. Will first forward this off list to the authors standing in the sources, so the bounces from the eventually non existent mails are not going back to the list (would spam everyone). But will then repeat the same to the list with valid mails. Regards Anatol --- ## #80869 — Anatol Belski — 2015-01-20T10:03:45+00:00 URL: https://externals.io/message/80838#80869 · In reply to: #80855 Hi, > > > > […] > > > Seriously I would also like to see all three in pecl. I am not saying > that they are not used nor maintained but a more flexible releases and > leave more options to the maintainer(s) could actually help. The main > problem here is the barrier to get a dev environment up and working, quite > high, especially for the 1st two. Interbase is easier but is a niche > server, so any kind of fixes or changes tightly related to how this DB > works require more than the usual suspects like pgsql, mysql or sqlite. > > I also do not like to use pecl as a cemetery for dead cows. After this > RFC, if some choices are actually accepted, let discuss how to deal > with that, from a pecl.php.net point of view. I would rather have them > marked dead and to do not appear in default search, a big warning on > install should be displayed as well (that's something I can take of if > desired). > > Maybe change the RFC title to reflect both kind of moves and them to the > list. > so this is an aggregated mail to involve everyone mentioned in the sources as maintainers of the corresponding parts. The initial RFC is here https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts and it's about handling yet not done stuff for PHP7. Additionally, it is suggested to handle these parts https://wiki.php.net/phpng#unsupported_extensions_not_converted_yet . The goal is to concentrate better on things really relevant for PHP7, that will also ease the porting efforts for new RFCs. At this point it's probably not late to port some stuff to PHP7 yet, but the general suggestion is to either remove or move to PECL. That's why we need responses about what the original maintainers are intended to do. Thanks Anatol --- ## #80888 — Jouni Ahto — 2015-01-20T19:18:13+00:00 URL: https://externals.io/message/80838#80888 · In reply to: #80866 At least one mail didn't bounce. The situation with Interbase extension, in my opinion: it's dead meat and should most probably be just removed. Nobody is currently, to my knowledge, maintaining it. Even the birth of said extension was a bit troublesome, when I had just for the fun of it written some very rudimentary code, committed it, and after that it turned out that Zeev was having a commercial negotiation about writing PHP support for it. Because we didn't want to step on each other toes, that left the the extension somewhat unmaintained for a while even then, and then I slowly dropped out of PHP development. Mostly because my new work in banking world had absolutely nothing to do with it, not because I would have been tired of it. It was extraordinarily fun and I somehow still miss those times. Kudos to everyone still working on PHP (I still recognize a few names on the mailing list) and to every newcomer. Now, this all happened when even PHP4 was still in development phase, a very long time ago, so I'm quite surprised that extension survived even into PHP5. Has anyone actually maintained it? PDO_FIREBIRD is probably a good replacement for it and it seems to be mentioned on the list of maintained extensions. I don't know how well it works with Interbase, which is now a proprietary product by Embarcadero Technologies. Firebird is an open source fork originating from the same codebase. It might even work, if the communication protocol with database hasn't changed (much) or can switch to some backwards compatible mode when encountering a version it does not recognize. And, last: funny coincidence that I received Anatol's email just now, when I've just a week ago opened a github account and already have several pull requests for 2 projects written in, surpricingly, PHP. Who knows, maybe like the Terminator, "I'll be back". Thanks for reading the rants of a really old fart. -- Jouni Ahto > Hi Dmitry, > > > > […] > I'm going to rename and update the RFC to handle these cases as well. > > Will first forward this off list to the authors standing in the sources, > so the bounces from the eventually non existent mails are not going back > to the list (would spam everyone). But will then repeat the same to the > list with valid mails. > > Regards > > Anatol --- ## #80889 — marius adrian popa — 2015-01-20T19:33:23+00:00 URL: https://externals.io/message/80838#80889 · In reply to: #80888 interbase extension is maintained and at least i will rename to firebird after php7 api conversion is over (a few blob/events tests don't pass after the big api changes ) Dmitry Stogov added some patches but we need to fix the zend engine api changes pdo_firebird is ok but doesn't cover the firebird api so we still need them both > At least one mail didn't bounce. > > The situation with Interbase extension, in my opinion: it's dead meat and > should most probably be just removed. Nobody is currently, to my knowledge, > maintaining it. Even the birth of said extension was a bit troublesome, > when I had just for the fun of it written some very rudimentary code, > committed it, and after that it turned out that Zeev was having a > commercial negotiation about writing PHP support for it. Because we didn't > want to step on each other toes, that left the the extension somewhat > unmaintained for a while even then, and then I slowly dropped out of PHP > development. Mostly because my new work in banking world had absolutely > nothing to do with it, not because I would have been tired of it. It was > extraordinarily fun and I somehow still miss those times. Kudos to everyone > still working on PHP (I still recognize a few names on the mailing list) > and to every newcomer. > > Now, this all happened when even PHP4 was still in development phase, a > very long time ago, so I'm quite surprised that extension survived even > into PHP5. Has anyone actually maintained it? > > PDO_FIREBIRD is probably a good replacement for it and it seems to be > mentioned on the list of maintained extensions. I don't know how well it > works with Interbase, which is now a proprietary product by Embarcadero > Technologies. Firebird is an open source fork originating from the same > codebase. It might even work, if the communication protocol with database > hasn't changed (much) or can switch to some backwards compatible mode when > encountering a version it does not recognize. > > And, last: funny coincidence that I received Anatol's email just now, when > I've just a week ago opened a github account and already have several pull > requests for 2 projects written in, surpricingly, PHP. Who knows, maybe > like the Terminator, "I'll be back". > > Thanks for reading the rants of a really old fart. > > -- Jouni Ahto > > > > > > […] --- ## #80891 — marius adrian popa — 2015-01-20T19:58:29+00:00 URL: https://externals.io/message/80838#80891 · In reply to: #80889 Here are the issues with master (008 is rounding issue so you can ignore for the moment) FAILED TEST SUMMARY --------------------------------------------------------------------- InterBase: BLOB test [ext/interbase/tests/004.phpt] InterBase: transactions [ext/interbase/tests/005.phpt] InterBase: array handling [ext/interbase/tests/007.phpt] InterBase: event handling [ext/interbase/tests/008.phpt] ibase_trans(): Basic test [ext/interbase/tests/ibase_trans_001.phpt] On Tue, Jan 20, 2015 at 9:33 PM, marius adrian popa wrote: > interbase extension is maintained and at least i will rename to firebird > after php7 api conversion is over (a few blob/events tests don't pass after > the big api changes ) > > Dmitry Stogov added > some patches but we need to fix the zend engine api changes > > pdo_firebird is ok but doesn't cover the firebird api so we still need > them both > > > > > […] --- ## #80893 — Jouni Ahto — 2015-01-20T20:09:34+00:00 URL: https://externals.io/message/80838#80893 · In reply to: #80889 Ok, in that case I'll take back some of my words. Would you please remove my name from the maintainers if it is still there? I don't expect to be able to contribute or fix anything anymore. -- Jouni Ahto > interbase extension is maintained and at least i will rename to firebird > after php7 api conversion is over (a few blob/events tests don't pass after > the big api changes ) > > Dmitry Stogov added > some patches but we need to fix the zend engine api changes > > pdo_firebird is ok but doesn't cover the firebird api so we still need them > both > > > > > […] --- ## #80897 — Lester Caine — 2015-01-20T20:31:00+00:00 URL: https://externals.io/message/80838#80897 · In reply to: #80889 > pdo_firebird is ok but doesn't cover the firebird api so we still need them > both And I would add to that - PDO does not allow cross database transactions which is another area interbase/firebird can utilise. It's particularly useful archiving historic data to a secondary database. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #80911 — johannes@schlueters.de — 2015-01-20T22:24:09+00:00 URL: https://externals.io/message/80838#80911 · In reply to: #80838 > Hi, > > I think the research on > https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts is now far enough > to be discussed. > > So far I only could not test sapi/nsapi because it needs a SunOs/IPlanet. > But independent from that, it'd make sense someone to recheck my > perceptions, or just the areas one is interested in. Uwe Schindler (CC'd) was he last one to maintain that, maybe he can help and knows whether this is still used. I know when Sun Microsystems still existed, there were a few users of this. I don't have any current knowledge. I assume, though, there still are, I don't know about effort/downsides of forcing them to change. johannes --- ## #80920 — Pierre Joye — 2015-01-21T03:43:58+00:00 URL: https://externals.io/message/80838#80920 · In reply to: #80889 > interbase extension is maintained and at least i will rename to firebird > after php7 api conversion is over (a few blob/events tests don't pass after > the big api changes ) There are two questions, maintained or dead cow. My worries about some of them listed are about the barrier to apply any kind of non trivial fixes and the use of this extension. For firebird, it is slightly less of a pain because the Firebird DB is relatively easy to setup while being a real niche server. Oracle, Sqlserver are easier cases. My feeling is that they are better in pecl, giving the maintainers more freedom to fix, improve, release, etc than being in the core while it can reduce the workload and overall quality in the core in the development phase. In any case, just like a couple of discussions lately, it is a taste matter. Imap or mcrypt, both dead cows, should go away. Let wait the required delay and move to vote. The sooner we take a decision the better. Cheers, Pierre