# Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4 - Thread: https://externals.io/message/121051 - Original archive: https://news-web.php.net/php.internals/121051 - Started by Derick Rethans on 2023-09-13T08:50:26+00:00 - Messages: 10 - RFC: Unbundle the imap, pspell, and oci8 extensions (Implemented (PHP 8.4)) — https://externals.io/rfc/unbundle_imap_pspell_oci8.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 --- ## #121051 — Derick Rethans — 2023-09-13T08:50:26+00:00 URL: https://externals.io/message/121051#121051 Hi, In a recent chat between the PHP Foundation developers, we discussed unbundling several extensions. ext/imap The library that provides the functionality in this extension, c-client, is no longer updated. The last release from 2007 is no longer available on the original distributor's (University of Washington) website, but there is an unofficial GitHub repository that hasn't been updated for 5 years either (https://github.com/uw-imap/imap). You can't also use this any more with G Suite due to authentication changes (https://github.com/uw-imap/imap/issues/4). There are several user-land packages that are still maintained, and provide superior functionality: - https://github.com/PHPMailer/PHPMailer - https://github.com/zetacomponents/Mail/ - https://github.com/symfony/mailer - https://github.com/laminas/laminas-mail ext/pspell The original underlying library hasn't been updated since 2001 (https://en.wikipedia.org/wiki/Pspell) and it's replacement, aspell not since 2019 (https://ftp.gnu.org/gnu/aspell/). There are other replacements, ispell, and hunspell, but they don't seem to be compatible API-wise. The PECL extension "enchant" was supposed to be able to use with all of these, but is also no longer maintained (last release in 2009, https://pecl.php.net/package/enchant). Again, there are several user land composer packages (https://packagist.org/?query=spell) that can be used instead. ext/oci8 Requires a proprietary library from large commercial enterprise (https://www.oracle.com/database/technologies/instant-client.html) and has many outstanding bugs: https://bugs.php.net/search.php?cmd=display&package_name[]=PDO+OCI&package_name[]=OCI8+related&package_name[]=Oracle+related&order_by=ts1&direction=ASC&limit=30&status=Open&reorder_by=ts1 https://github.com/php/php-src/labels/Extension%3A%20oci8 Most of the recent changes were all to skip tests. It is also one of the larger extensions left that had not had their resource type converted to objects. This is a major effort, and frankly, probably something that should be done by the corporate sponsor of the oracle extensions. Please remember, that unbundling extensions does not mean that they disappear. They will be moved to PECL with a release made. An RFC will of course be forthcoming, but we thought it best to email the list first. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug --- ## #121054 — Vinicius Dias — 2023-09-13T17:29:11+00:00 URL: https://externals.io/message/121051#121054 · In reply to: #121051 > ext/imap > > The library that provides the functionality in this extension, c-client, > is no longer updated. The last release from 2007 is no longer available > on the original distributor's (University of Washington) website, but > there is an unofficial GitHub repository that hasn't been updated for 5 > years either (https://github.com/uw-imap/imap). > > You can't also use this any more with G Suite due to authentication > changes (https://github.com/uw-imap/imap/issues/4). > > There are several user-land packages that are still maintained, and > provide superior functionality: > > - https://github.com/PHPMailer/PHPMailer > - https://github.com/zetacomponents/Mail/ > - https://github.com/symfony/mailer > - https://github.com/laminas/laminas-mail > Those alternatives are for sending e-mails. IMAP is for reading e-mails. They are not equivalent. Am I missing something here? Vinicius Dias, Zend Certified Engineer, iMasters PHP Certified Professional Em qua., 13 de set. de 2023 às 05:50, Derick Rethans escreveu: > > Hi, > > In a recent chat between the PHP Foundation developers, we discussed > unbundling several extensions. > > > ext/imap > > The library that provides the functionality in this extension, c-client, > is no longer updated. The last release from 2007 is no longer available > on the original distributor's (University of Washington) website, but > there is an unofficial GitHub repository that hasn't been updated for 5 > years either (https://github.com/uw-imap/imap). > > You can't also use this any more with G Suite due to authentication > changes (https://github.com/uw-imap/imap/issues/4). > > There are several user-land packages that are still maintained, and > provide superior functionality: > > - https://github.com/PHPMailer/PHPMailer > - https://github.com/zetacomponents/Mail/ > - https://github.com/symfony/mailer > - https://github.com/laminas/laminas-mail > > > ext/pspell > > The original underlying library hasn't been updated since 2001 > (https://en.wikipedia.org/wiki/Pspell) and it's replacement, aspell not > since 2019 (https://ftp.gnu.org/gnu/aspell/). > > There are other replacements, ispell, and hunspell, but they don't seem > to be compatible API-wise. The PECL extension "enchant" was supposed > to be able to use with all of these, but is also no longer maintained > (last release in 2009, https://pecl.php.net/package/enchant). > > Again, there are several user land composer packages > (https://packagist.org/?query=spell) that can be used instead. > > > ext/oci8 > > Requires a proprietary library from large commercial enterprise > (https://www.oracle.com/database/technologies/instant-client.html) and > has many outstanding bugs: > https://bugs.php.net/search.php?cmd=display&package_name[]=PDO+OCI&package_name[]=OCI8+related&package_name[]=Oracle+related&order_by=ts1&direction=ASC&limit=30&status=Open&reorder_by=ts1 > https://github.com/php/php-src/labels/Extension%3A%20oci8 > > Most of the recent changes were all to skip tests. > > It is also one of the larger extensions left that had not had their > resource type converted to objects. This is a major effort, and frankly, > probably something that should be done by the corporate sponsor of the > oracle extensions. > > > Please remember, that unbundling extensions does not mean that they > disappear. They will be moved to PECL with a release made. > > An RFC will of course be forthcoming, but we thought it best to email > the list first. > > > cheers, > Derick > > -- > https://derickrethans.nl | https://xdebug.org | https://dram.io > > Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support > Host of PHP Internals News: https://phpinternals.news > > mastodon: @derickr@phpc.social @xdebug@phpc.social > twitter: @derickr and @xdebug > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #121056 — Ayesh Karunaratne — 2023-09-13T17:50:45+00:00 URL: https://externals.io/message/121051#121056 · In reply to: #121054 > > […] > > Those alternatives are for sending e-mails. IMAP is for reading > e-mails. They are not equivalent. > Am I missing something here? > You are right that PHPMailer, laminas and Symfony Mailer are for sending emails, but Zeta supports retrieving email over IMAP. https://packagist.org/packages/webklex/php-imap is a popular and active alternative as well. Considering the lack of updates from upstream as Derick mentioned, lack of OAuth support (which webklex/php-imap supports), and a somewhat lackluster documentation for ext-imap in php.net, I think unbundling ext-imap (along with the other extensions in the proposal) makes sense. --- ## #121069 — BohwaZ — 2023-09-15T15:54:50+00:00 URL: https://externals.io/message/121051#121069 · In reply to: #121056 > Considering the lack of updates from upstream as Derick mentioned, > lack of OAuth support (which webklex/php-imap supports), and a > somewhat lackluster documentation for ext-imap in php.net, I think > unbundling ext-imap (along with the other extensions in the proposal) > makes sense. I don't think that OAuth support is an argument, as most providers don't support OAuth, so the imap package might still be relevant for people who are not using Google. Also, the package currently works, IMAP is a stable protocol, maybe this library is just stable? I'm not against the removal, but having to rely on user-space libraries probably means we'll lose some performance over using the C library. Also, some widely-used libraries like php-imap use it: https://packagist.org/packages/php-imap/php-imap Personally I'm using curl for IMAP, as it is more widely available, but I think removing php-imap might be a bit too early, except if keeping it does require a lot of time / effort? --- ## #121070 — Hartmut Holzgraefe — 2023-09-15T16:05:55+00:00 URL: https://externals.io/message/121051#121070 · In reply to: #121069 > I'm not against the removal, but having to rely on user-space libraries > probably means we'll lose some performance over using the C library. to quote from the message that started this thread: "Please remember, that unbundling extensions does not mean that they disappear. They will be moved to PECL with a release made." I have fond memories of ext/imap back in the days (it basically was one of the key reasons for me getting involved with PHP in the first place back then), but even without the upstream lack of maintenance situation it should probably have long moved to PECL already ... -- hartmut --- ## #121071 — Remi Collet — 2023-09-15T17:18:38+00:00 URL: https://externals.io/message/121051#121071 · In reply to: #121051 Le 13/09/2023 à 10:50, Derick Rethans a écrit : > Hi, > > In a recent chat between the PHP Foundation developers, we discussed > unbundling several extensions. > > > ext/imap +1 > ext/pspell +1 > There are other replacements, ispell, and hunspell, but they don't seem > to be compatible API-wise. The PECL extension "enchant" was supposed > to be able to use with all of these, but is also no longer maintained > (last release in 2009, https://pecl.php.net/package/enchant). Notice that enchant is part of php-src (since 5.3) and use libenchant v2 which is actively maintained. Support for v1 is still there and should probably be dropped > ext/oci8 +1 Remi --- ## #121151 — Derick Rethans — 2023-09-27T13:14:16+00:00 URL: https://externals.io/message/121051#121151 · In reply to: #121069 > > […] > > I don't think that OAuth support is an argument, as most providers > don't support OAuth, so the imap package might still be relevant for > people who are not using Google. > > Also, the package currently works, IMAP is a stable protocol, maybe > this library is just stable? > > I'm not against the removal, but having to rely on user-space > libraries probably means we'll lose some performance over using the C > library. > > Also, some widely-used libraries like php-imap use it: > https://packagist.org/packages/php-imap/php-imap The ext/imap extension isn't going to disappear, it is not going be unbundled as we can not guarantee the underlaying library is maintained. Not only is it no longer maintained, the original purveyors have removed any mention of it from their website. For most people, there will be little change here. On Debian for example, "php-" is used for both bundled and PECL'ed extensions. > Personally I'm using curl for IMAP, as it is more widely available, > but I think removing php-imap might be a bit too early, except if > keeping it does require a lot of time / effort? Using Curl seems like a bad alternative, as it would likely have to open a connection for each action that you do. cheers, Derick --- ## #121158 — BohwaZ — 2023-09-28T09:48:34+00:00 URL: https://externals.io/message/121051#121158 · In reply to: #121151 > The ext/imap extension isn't going to disappear, it is not going be > unbundled as we can not guarantee the underlaying library is > maintained. Not only is it no longer maintained, the original > purveyors have removed any mention of it from their website. > > For most people, there will be little change here. On Debian for > example, "php-" is used for both bundled and PECL'ed > extensions. OK then :) > Using Curl seems like a bad alternative, as it would likely have to > open a connection for each action that you do. No, curl is clever and keeping the connection open as long as you don't use curl_close. This is clearly visible when enabling verbose mode: … < A004 OK Fetch completed (0.001 + 0.000 secs). * Connection #0 to host localhost left intact * Found bundle for host localhost: 0x55d0b5c60f50 [serially] * Re-using existing connection! (#0) with host localhost * Connected to localhost (127.0.0.1) port 143 (#0) > A005 FETCH 1:* FULL … In my experience, using curl is much faster than using ext/imap :) --- ## #121159 — Jakub Zelenka — 2023-09-28T10:29:44+00:00 URL: https://externals.io/message/121051#121159 · In reply to: #121151 > > > > […] > > The ext/imap extension isn't going to disappear, it is not going be > unbundled as we can not guarantee the underlaying library is maintained. > Not only is it no longer maintained, the original purveyors have removed > any mention of it from their website. > > For most people, there will be little change here. On Debian for > example, "php-" is used for both bundled and PECL'ed > extensions. > Although it's unlikely that it gets any maintainer so it will most likely stop building and won't be available in the future PHP versions. I think we should be clear about this and note that those extensions will no longer be supported by PHP core dev team which likely means their end at some point in the future unless someone steps in to maintain them. Cheers Jakub --- ## #121218 — Derick Rethans — 2023-10-03T10:31:25+00:00 URL: https://externals.io/message/121051#121218 · In reply to: #121159 > > > > […] > > Although it's unlikely that it gets any maintainer so it will most > likely stop building and won't be available in the future PHP > versions. I think we should be clear about this and note that those > extensions will no longer be supported by PHP core dev team which > likely means their end at some point in the future unless someone > steps in to maintain them. I have added words describing that to the RFC. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug