Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103706
MIME-Version: 1.0
References: <519a993a-98fb-8343-6565-29b8245ada63@gmx.de>
In-Reply-To: <519a993a-98fb-8343-6565-29b8245ada63@gmx.de>
Date: Wed, 9 Jan 2019 12:34:18 -0600
Message-ID: <CAESVnVoyUWFkkqv_JUME3qxVw-ptfJkZb=ORCOmu2LaCH7wVpA@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005e90fb057f0ab6e3"
Subject: Re: [PHP-DEV] What to do with ext/xmlrpc?
From: pollita@php.net (Sara Golemon)

--0000000000005e90fb057f0ab6e3
Content-Type: text/plain; charset="UTF-8"

On Wed, Jan 9, 2019 at 6:28 AM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> The problem with ext/xmlrpc is that it relies on libxmlrpc-epi[1], which
> looks abandoned.  Even worse, we're bundling a modified 0.51[2], while
> the latest version is 0.54.1[3].  This is exacerbated by the fact that
> the system library is usually build against libexpat, but the bundled
> library is likely to be build against libxml2 using our compat layer.
>
> We most recently fixed two security issues[4], but it is likely not
> clear whether these may affect latest system libraries as well, and
> there are more issues.
>
> So unless a maintainer steps forward, it might be best to deprecate
> and/or unbundle ext/xmlrpc.
>
> IMO, xmlrpc is one of those extensions which could trivially be
re-implemented as pure PHP code.  It would depend on ext/dom or similar for
serde, but everything else is just business logic that can be lifted out of
the runtime and probably made WAY better.  In fact, a quick google says
something in that spirit already exits:
https://packagist.org/packages/phpxmlrpc/phpxmlrpc

I don't think we need to put energy into finding maintainers for extensions
which don't need to exist.  Send it to Siberia, afaic.

-Sara

--0000000000005e90fb057f0ab6e3--