deprecating xml-rpc and package.xml 1.0

From: 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

« previous php.pear.dev (#44639) next »