(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 libxmlrpc-epi.so 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, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office.
pgpr3G9wJr1Pr.pgp
Description: PGP signature
