Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC} Deprecate and Remove ext/wwdx »

[RFC} Deprecate and Remove ext/wwdx

php.internals

Christoph Becker

7 years ago
Hi! Finally, I hereby put the “Deprecate and Remove ext/wwdx” RFC[1] under discussion. [1] <https://wiki.php.net/rfc/deprecate-and-remove-ext-wddx>
-- Christoph M. Becker

Sebastian Bergmann

7 years ago
On 9/16/18 12:48 PM, Christoph M. Becker wrote:
> Finally, I hereby put the “Deprecate and Remove ext/wwdx” RFC[1] under > discussion.
+1. I have never seen this used anywhere.

Stas Malyshev

7 years ago
Hi!
> On 9/16/18 12:48 PM, Christoph M. Becker wrote: >> Finally, I hereby put the “Deprecate and Remove ext/wwdx” RFC[1] under >> discussion.
I assume it should be ext/wddx?
-- Stas Malyshev smalyshev@gmail.com

Christoph Becker

7 years ago
On 17.09.2018 at 21:28, Stanislav Malyshev wrote:
>> On 9/16/18 12:48 PM, Christoph M. Becker wrote: >> >>> Finally, I hereby put the “Deprecate and Remove ext/wwdx” RFC[1] under >>> discussion. > > I assume it should be ext/wddx?
Oops! Thanks, fixed now.
-- Christoph M. Becker

Stas Malyshev

7 years ago
Hi! About the RFC - I think we can/should move it to PECL in 7.4 but need no deprecation messages if we do. If somebody is using it, deprecation messages would just annoy them, since there's no easy way to switch except rewrite the code to use completely different extension (which would probably require significant code rewrite).
-- Stas Malyshev smalyshev@gmail.com

Christoph Becker

7 years ago
On 18.09.2018 at 00:51, Stanislav Malyshev wrote:
> About the RFC - I think we can/should move it to PECL in 7.4 but need no > deprecation messages if we do. If somebody is using it, deprecation > messages would just annoy them, since there's no easy way to switch > except rewrite the code to use completely different extension (which > would probably require significant code rewrite).
Hmm, I have some doubts that it's okay for users if we remove the WDDX extension in PHP 7.4 without any deprecation phase. Is there any precedence of doing so? The deprecation and removal of MCrypt appears to be somwehat comparable, but instead of moving it to PECL with PHP 7.1, we deprecated all functions and moved it to PECL with PHP 7.2. Furthermore, the deprecation notices *are* annoying, and it seems to me that is good, because probably nobody should continue to use these functions. They're unsafe for general data change, and there are likely better alternatives for the safe cases. Don't get me wrong: I like to unbundle the WDDX extension with the least possible effort as soon as possible, but dropping it appears to be simpler as possible.
-- Christoph M. Becker

Stas Malyshev

7 years ago
Hi!
> Hmm, I have some doubts that it's okay for users if we remove the WDDX > extension in PHP 7.4 without any deprecation phase. Is there any
I think deprecation phase is necessary for features that are being removed. For extension being moved to PECL I do not see any point in annoying the users for a year with error messages. If they need it, they'll keep using it anyway, if they do not, they'll drop it - but deprecation messages here do not add much value that one single announcement can't make.
> Furthermore, the deprecation notices *are* annoying, and it seems to me > that is good, because probably nobody should continue to use these > functions. They're unsafe for general data change, and there are likely
Well, if we think nobody should use them then it's not move to PECL, it's discontinuation of the extension. These two are completely different cases.
> Don't get me wrong: I like to unbundle the WDDX extension with the least > possible effort as soon as possible, but dropping it appears to be > simpler as possible.
If it's still available in PECL, whoever needs it would easily get it there. If we think it's unusable anymore, then we need to declare that and not move it to PECL but sunset it.
-- Stas Malyshev smalyshev@gmail.com

Nikita Popov

7 years ago
On Wed, Sep 19, 2018 at 12:24 AM Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi! > > > Hmm, I have some doubts that it's okay for users if we remove the WDDX > > extension in PHP 7.4 without any deprecation phase. Is there any > > I think deprecation phase is necessary for features that are being > removed. For extension being moved to PECL I do not see any point in > annoying the users for a year with error messages. If they need it, > they'll keep using it anyway, if they do not, they'll drop it - but > deprecation messages here do not add much value that one single > announcement can't make. > > > Furthermore, the deprecation notices *are* annoying, and it seems to me > > that is good, because probably nobody should continue to use these > > functions. They're unsafe for general data change, and there are likely > > Well, if we think nobody should use them then it's not move to PECL, > it's discontinuation of the extension. These two are completely > different cases. > > > Don't get me wrong: I like to unbundle the WDDX extension with the least > > possible effort as soon as possible, but dropping it appears to be > > simpler as possible. > > If it's still available in PECL, whoever needs it would easily get it > there. If we think it's unusable anymore, then we need to declare that > and not move it to PECL but sunset it. >
We have deprecated and moved to PECL a number of extensions in the recent past. These were mysql and ereg in PHP 7.0 and mcrypt in PHP 7.2. I have always understood these moves as "sunsetting" the extensions, in the sense of strongly discouraging their continued use, as well as removing any promise of further maintenance. The move to PECL rather than outright deletion of the code is just a matter of general policy (or so I thought). Especially for an extension such as ext/wddx where we have legitimate security concerns, just moving it off to PECL without any deprecation warnings would send the wrong kind of signal. I would prefer it to stick the the same process we have used for other extensions in the past (i.e. first deprecate everything and then archive it in PECL.) Regards, Nikita

Stas Malyshev

7 years ago
Hi!
> We have deprecated and moved to PECL a number of extensions in the > recent past. These were mysql and ereg in PHP 7.0 and mcrypt in PHP 7.2. > I have always understood these moves as "sunsetting" the extensions, in > the sense of strongly discouraging their continued use, as well as > removing any promise of further maintenance. The move to PECL rather > than outright deletion of the code is just a matter of general policy > (or so I thought).
I think we should distinguish between the two cases - not having extension in core and deprecating the extension. Unless we declare that the only function of PECL now is to serve as a graveyard for archival of deprecated code. I don't think we really want to do that? If yes, than we should distinguish between deprecating the extension and just moving it to PECL.
-- Stas Malyshev smalyshev@gmail.com

Nikita Popov

7 years ago
On Thu, Sep 20, 2018 at 7:02 PM Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi! > > > We have deprecated and moved to PECL a number of extensions in the > > recent past. These were mysql and ereg in PHP 7.0 and mcrypt in PHP 7.2. > > I have always understood these moves as "sunsetting" the extensions, in > > the sense of strongly discouraging their continued use, as well as > > removing any promise of further maintenance. The move to PECL rather > > than outright deletion of the code is just a matter of general policy > > (or so I thought). > > I think we should distinguish between the two cases - not having > extension in core and deprecating the extension. Unless we declare that > the only function of PECL now is to serve as a graveyard for archival of > deprecated code. I don't think we really want to do that? If yes, than > we should distinguish between deprecating the extension and just moving > it to PECL. >
Sure, generally speaking we can also move an extension to PECL without deprecation -- for example if it does not appear to be commonly used anymore and we do not want to maintain it in php-src, but otherwise nothing is wrong with the extension and its use. However, this is not the case for the last three moves to PECL we did. In those cases we always wanted to explicitly discourage further use of the extension. The same is true for ext/wddx. It's not just a matter of nobody using WDDX in 2018, we also have specific security concerns which make continued use of this extension dangerous. If your code breaks because we dropped ext/wddx, you should not be able to type "pecl install wddx" and go back to ignoring the issue. By the way, I'm fine with moving the extension to PECL already in PHP 7.4, the part that's important to me is that it's going to generate some form of diagnostics once in PECL. Nikita

Christoph Becker

7 years ago
On 19.09.2018 at 00:24, Stanislav Malyshev wrote:
>> Hmm, I have some doubts that it's okay for users if we remove the WDDX >> extension in PHP 7.4 without any deprecation phase. Is there any > > I think deprecation phase is necessary for features that are being > removed. For extension being moved to PECL I do not see any point in > annoying the users for a year with error messages. If they need it, > they'll keep using it anyway, if they do not, they'll drop it - but > deprecation messages here do not add much value that one single > announcement can't make.
Okay, I get your point. The accepted “Cleaning up unmaintained extensions” RFC[1] suggests to move to PECL without any deprecation, so it seems to me we should follow that RFC (i.e. start with a call for maintainership). [1] <https://wiki.php.net/rfc/umaintained_extensions>
-- Christoph M. Becker

Nikita Popov

7 years ago
On Sun, Sep 16, 2018 at 6:49 PM Christoph M. Becker <cmbecker69@gmx.de> wrote:
> Hi! > > Finally, I hereby put the “Deprecate and Remove ext/wwdx” RFC[1] under > discussion. > > [1] <https://wiki.php.net/rfc/deprecate-and-remove-ext-wddx>
Do you plan to move this RFC forward to voting? I think during the discussion the consensus basically was that we want to move this to PECL ASAP (i.e. already in 7.4) and there was some disagreement on whether it should also throw deprecation warnings. I would prefer that, but in the end what's most important is that the extension is unbundled. Nikita

Christoph Becker

7 years ago
On 14.01.2019 at 10:45, Nikita Popov wrote:
> On Sun, Sep 16, 2018 at 6:49 PM Christoph M. Becker <cmbecker69@gmx.de> > wrote: > >> Finally, I hereby put the “Deprecate and Remove ext/wwdx” RFC[1] under >> discussion. >> >> [1] <https://wiki.php.net/rfc/deprecate-and-remove-ext-wddx> > > Do you plan to move this RFC forward to voting? > > I think during the discussion the consensus basically was that we want to > move this to PECL ASAP (i.e. already in 7.4) and there was some > disagreement on whether it should also throw deprecation warnings. I would > prefer that, but in the end what's most important is that the extension is > unbundled.
Thanks for the reminder! I have updated the RFC to have a primary vote on whether to unbundle ext/wddx or not, and a secondary vote on the detailed procedure. I guess that I have caught all suggestions so far, and although I don't like these secondary votes, it seems we can't do without here.
-- Christoph M. Becker

Nikita Popov

7 years ago
On Mon, Jan 14, 2019 at 12:22 PM Christoph M. Becker <cmbecker69@gmx.de> wrote:
> On 14.01.2019 at 10:45, Nikita Popov wrote: > > > On Sun, Sep 16, 2018 at 6:49 PM Christoph M. Becker <cmbecker69@gmx.de> > > wrote: > > > >> Finally, I hereby put the “Deprecate and Remove ext/wwdx” RFC[1] under > >> discussion. > >> > >> [1] <https://wiki.php.net/rfc/deprecate-and-remove-ext-wddx> > > > > Do you plan to move this RFC forward to voting? > > > > I think during the discussion the consensus basically was that we want to > > move this to PECL ASAP (i.e. already in 7.4) and there was some > > disagreement on whether it should also throw deprecation warnings. I > would > > prefer that, but in the end what's most important is that the extension > is > > unbundled. > > Thanks for the reminder! > > I have updated the RFC to have a primary vote on whether to unbundle > ext/wddx or not, and a secondary vote on the detailed procedure. I > guess that I have caught all suggestions so far, and although I don't > like these secondary votes, it seems we can't do without here. > > -- > Christoph M. Becker >
Is the "dump the extension for PHP 7.4" option to remove the extension without putting it up on PECL? Nikita

Christoph Becker

7 years ago
On 14.01.2019 at 12:46, Nikita Popov wrote:
> On Mon, Jan 14, 2019 at 12:22 PM Christoph M. Becker <cmbecker69@gmx.de> > wrote: > >> On 14.01.2019 at 10:45, Nikita Popov wrote: >> >>> On Sun, Sep 16, 2018 at 6:49 PM Christoph M. Becker <cmbecker69@gmx.de> >>> wrote: >>> >>>> Finally, I hereby put the “Deprecate and Remove ext/wwdx” RFC[1] under >>>> discussion. >>>> >>>> [1] <https://wiki.php.net/rfc/deprecate-and-remove-ext-wddx> >>> >>> Do you plan to move this RFC forward to voting? >>> >>> I think during the discussion the consensus basically was that we want to >>> move this to PECL ASAP (i.e. already in 7.4) and there was some >>> disagreement on whether it should also throw deprecation warnings. I >> would >>> prefer that, but in the end what's most important is that the extension >> is >>> unbundled. >> >> Thanks for the reminder! >> >> I have updated the RFC to have a primary vote on whether to unbundle >> ext/wddx or not, and a secondary vote on the detailed procedure. I >> guess that I have caught all suggestions so far, and although I don't >> like these secondary votes, it seems we can't do without here. > > Is the "dump the extension for PHP 7.4" option to remove the extension > without putting it up on PECL?
Yes. This option has been brought up by Stas[1], so I've added it. [1] <https://externals.io/message/103164#103178>
-- Christoph M. Becker