Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103267
To: Nikita Popov <nikita.ppv@gmail.com>,
 Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <5518056b-150f-517c-2c24-09d5da4414f0@gmx.de>
 <d290481d-be6c-3dea-2054-a486e37c1231@php.net>
 <3a3a59bf-98a3-764d-def2-e514f506edfc@gmail.com>
 <2e82ff1a-7045-3b7e-3feb-bfdac29883e9@gmx.de>
 <2f30a0da-c15a-8723-bebd-4143d49cf032@gmail.com>
 <d20a72fa-656a-b528-90f7-63f631aded87@gmx.de>
 <7fbac401-d15f-e7fe-2792-41f5c8cea411@gmail.com>
 <CAF+90c9UXA5jfYHKZtsBeMDMsA-E-fh6hYtjowbhGQaoj0PsGA@mail.gmail.com>
 <f465b612-021d-3eb9-de73-cad69aac4ce4@gmail.com>
 <CAF+90c-LP7e1AT9u=tTw5J6spRQdXe-Z6=eu7izENyZn6O5ZUg@mail.gmail.com>
Message-ID: <4499b764-c323-15de-6735-2f67ac83116b@gmx.de>
Date: Thu, 27 Sep 2018 11:16:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c-LP7e1AT9u=tTw5J6spRQdXe-Z6=eu7izENyZn6O5ZUg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC} Deprecate and Remove ext/wddx
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 25.09.2018 at 14:08, Nikita Popov wrote:

> 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