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
Finally, I hereby put the “Deprecate and Remove ext/wwdx” RFC[1] under
discussion.
+1. I have never seen this used anywhere.
Hi!
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
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
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
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
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
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 anyI 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 likelyWell, 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
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
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
On Thu, Sep 20, 2018 at 7:02 PM Stanislav Malyshev smalyshev@gmail.com
wrote: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.
We may also consider to only deprecate the object deserialization, and
move to PECL right away, which has been suggested by Zeev a year ago[1].
Anyhow, I really don't mind what exactly we do with ext/wddx, but
rather that we do something. We had this discussion already last
year, but nothing happened. I'm not keen to change the RFC to offer
multiple choices (since I feel this is generally suboptimal),
particularly if we had:
- Deprecate
- deprecate all functionality
- deprecate object deserialization only
- don't deprecate anything
- (Re)move
- Move to PECL
- sunset the extension
- PHP Version
- PHP 7.4
- PHP 8
[1] https://externals.io/message/100183#100209
--
Christoph M. Becker
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 anyI 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
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.
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
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.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
On Mon, Jan 14, 2019 at 12:22 PM Christoph M. Becker cmbecker69@gmx.de
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.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
On Mon, Jan 14, 2019 at 12:22 PM Christoph M. Becker cmbecker69@gmx.de
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.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