[php-maint] xmlrpc-epi turns out to be libxmlrpc in php
Paul TBBle Hampson
Paul.Hampson at Pobox.com
Sat Mar 10 17:05:58 CET 2007
(For the php-maint team. I've just ITP'd xmlrpc-epi as a dependancy
of the second-life client, and was poking around to see if there was
a good way of not having to package it.)
Interestingly, the code in ext/xmlrpc/libxmlrpc in the php5 5.2.0
tarball is a derivative of xmlrpc-epi. A quick check of the headers
indicates no API changes (just some ANSI C fixes). I haven't looked at
the code changes yet, but I'm not expecting anything API-breaking.
(I'd read on the site that it went into PHP 4.1, but I'd not clicked
that meant the actual xmlrpc-epi source had slipped into the PHP tree,
nor did I realise PHP5 was still using it, since I thought they'd
rewritten the xmlrpc extension in PHP5...)
The PHP5 version compiles the xmlrpc-epi code plus the PHP5 extension
code xmlrpc-epi-php.c together into one .so file.
Would there be any interest in having PHP5 link its xmlrpc extension
against a distinct library packaging of xmlrpc-epi? (ie. to avoid
the situation which once existed for zlib being statically compiled
into various other packages, causing security headaches...)
xmlrpc-epi seems like a useful standalone library to me, since
(unlike libxmlrpc-c3) it doesn't include a network transport layer,
allowing the actual transport to be handled by the user, and it's
in C (unlike libxmlrpc++). And second-life client will be user number 2,
that I know of.
Of course, if PHP5 was using an external xmlrpc-epi library, it
would have to be something other than /usr/lib/libxmlrpc.so, as
that's already taken by libxmlrpc-c3. Interestingly Mandriva and PLD
both consider libxmlrpc-epi to be /usr/lib/libxmlrpc.so and libxmlrpc-c3
is instead /usr/lib/libxmlrpc-c.so. Gentoo appears to be happy to have
them both be libxmlrpc.so, and FreeBSD's ports collection conflicts
them. So the naming field is wide open. I'm leaning towards
I plan to go through the changes to the library in PHP5 and see if
there's anything that would preclude general use. I suspect many of the
.c changes were the result of either bugfixes that I want, or the
conversion to use a modern expat API rather than the API circa 2000,
which I've also done to my copy of xmlrpc-epi.
On a side note, config.m4 in ext/xmlrpc is currently forcing the
xmlrpc-epi version to 0.50, even though comments in the code in the
libxmlrpc directory indicate it was later synced up with 0.51 (the last
upstream release of xmlrpc-epi).
Paul "TBBle" Hampson, Paul.Hampson at Pobox.com
Shorter .sig for a more eco-friendly paperless office.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20070311/13a6e07d/attachment.pgp
More information about the pkg-php-maint