deprecating xml-rpc and package.xml 1.0
| From: | Gregory Beaver | Date: | Thu, 19 Oct 2006 01:52:23 +0000 |
| Subject: | deprecating xml-rpc and package.xml 1.0 | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-44639@lists.php.net to get a copy of this message | ||
Hi,
As you can see from the stats page I've put up at
http://pear.php.net/~greg/stats/
we no longer have any significant usage of PEAR 1.3 to download
packages. This is a good sign of the adoption rate of PEAR 1.4.x, and I
think it is time to deprecate package.xml 1.0 and specifically the
xml-rpc server. Deprecation does *not* mean disabling. It means
putting out a big warning that 1 year from now we will turn off the
server, and notify as many sources as possible. In particular, we need
to talk to Zend and figure out their who's who app. Disabling any
sooner than 1 year after the announcement would be fallacy in my opinion.
A more accurate track of who is actually using xml-rpc is available
through the stats page Martin runs. Here is a comparison:
http://pear.php.net/~mj/stats/usage_200510.php
an excerpt of most visited pages and the size of returned data:
1 321022 3.86% 1766799 2.22% /login.php
2 265838 3.19% 2379648 2.98% /feeds/latest.rss
3 195529 2.35% 9551601 11.98% /xmlrpc.php
...
9 95071 1.14% 47497 0.06% /channel.xml
http://pear.php.net/~mj/stats/usage_200609.php
2 390283 2.82% 64601 0.06% /channel.xml
...
11 177799 1.28% 1325637 1.20% /gifs/favicon.ico
12 169011 1.22% 896137 0.81% /bugs/bug.php
13 157197 1.14% 6743490 6.13% /xmlrpc.php
As you can see, requests for xmlrpc.php have traded places with requests
for channel.xml.
Also important to note is that the decline in requests to xmlrpc.php is
actually not very large volume-wise, underscoring the need for a long
time period between deprecation and removal. It also shows why we need
to make a formal move for this to happen.
Why, you might ask, should we deprecate xml-rpc? The xml-rpc requests
are a serious drag on the server, and make it very difficult to
re-factor the web site, something that is not true of REST. Funneling
all data through a PHP pipe is always less efficient than serving static
files generated on release, and moving the processing to the client side.
In addition, the PEAR Installer doesn't use XML-RPC, in fact, it doesn't
even install the package by default any longer.
Comments?
Greg