If I understood correctly, the fixed XML_RPC pear package
was updated to the PHP_5_1 branch already. Why is ext/xmlrpc
still required?
--Jani
Jani Taskinen wrote:
If I understood correctly, the fixed XML_RPC pear package was updated to the PHP_5_1 branch already. Why is ext/xmlrpc still required?
It isn't.
Jani Taskinen wrote:
If I understood correctly, the fixed XML_RPC pear package was updated to the PHP_5_1 branch already. Why is ext/xmlrpc still required?It isn't.
Ok. Fix committed. :)
--Jani
On that line though, I'd like to finish up the ext/xmlrpci ext I've got
in PECL and replace ext/xmlrpc. It'll eliminate the custom lib we have
for that ext, ground-up designed for PHP 5 (ext/soap style overloading,
etc.) Objections?
Cheers,
John
Jani Taskinen wrote:
If I understood correctly, the fixed XML_RPC pear package was updated to the PHP_5_1 branch already. Why is ext/xmlrpc still required?It isn't.
Ok. Fix committed. :) --Jani
'Replace'? Code written for ext/xmlrpc won't work with ext/xmlrpci. Will
ext/xmlrpc be available in PECL, given that it doesn't appear to have an
active maintainer?
I'm well aware of ext/xmlrpc's limitations, haven't tried the new (but
necessary) pecl/xmlrpci yet, and have the tiny issue that a bunch of my
scripts will need a complete rewrite if the old extension is simply taken
away from PHP 5 up. I suspect I'm far from being alone in that - do we have
figures for core extension usage, anyone?
----- Original Message -----
From: "John Coggeshall" john@coggeshall.org
To: "Jani Taskinen" sniper@iki.fi
Cc: "Rasmus Lerdorf" rasmus@lerdorf.com; internals@lists.php.net;
rasmus@php.net
Sent: Sunday, August 28, 2005 3:42 AM
Subject: Re: [PHP-DEV] Re: PHP 5.1: Does it still require ext/xmlrpc for
pear?
On that line though, I'd like to finish up the ext/xmlrpci ext I've got
in PECL and replace ext/xmlrpc. It'll eliminate the custom lib we have
for that ext, ground-up designed for PHP 5 (ext/soap style overloading,
etc.) Objections?Cheers,
John
Jani Taskinen wrote:
If I understood correctly, the fixed XML_RPC pear package was updated to the PHP_5_1 branch already. Why is ext/xmlrpc still required?It isn't.
Ok. Fix committed. :) --Jani
'Replace'? Code written for ext/xmlrpc won't work with ext/xmlrpci. Will
ext/xmlrpc be available in PECL, given that it doesn't appear to have an
active maintainer?
Sure it'll be in PECL, just like dio, crack, yaz, and the other half
dozen or so extensions we've removed from PHP 5 ext/ and into PECL.
I'm well aware of ext/xmlrpc's limitations, haven't tried the new (but
necessary) pecl/xmlrpci yet, and have the tiny issue that a bunch of my
scripts will need a complete rewrite if the old extension is simply taken
away from PHP 5 up. I suspect I'm far from being alone in that - do we have
figures for core extension usage, anyone?
Well considering we've done it already with a number of extensions, I
don't see a big issue. Note also that I'm not hugely concerned with
when this happens (read: What version of PHP the change is made).
Although there could be a bunch of compat functions to emulate the old
xmlrpc behavior,I'm against it simply because there is nothing stopping
someone from having both extensions loaded.
----- Original Message -----
From: "John Coggeshall" john@coggeshall.org
To: "Jani Taskinen" sniper@iki.fi
Cc: "Rasmus Lerdorf" rasmus@lerdorf.com; internals@lists.php.net;
rasmus@php.net
Sent: Sunday, August 28, 2005 3:42 AM
Subject: Re: [PHP-DEV] Re: PHP 5.1: Does it still require ext/xmlrpc for
pear?On that line though, I'd like to finish up the ext/xmlrpci ext I've got
in PECL and replace ext/xmlrpc. It'll eliminate the custom lib we have
for that ext, ground-up designed for PHP 5 (ext/soap style overloading,
etc.) Objections?Cheers,
John
Jani Taskinen wrote:
If I understood correctly, the fixed XML_RPC pear package was updated to the PHP_5_1 branch already. Why is ext/xmlrpc still required?It isn't.
Ok. Fix committed. :) --Jani
'Replace'? Code written for ext/xmlrpc won't work with ext/xmlrpci.
Will
ext/xmlrpc be available in PECL, given that it doesn't appear to have an
active maintainer?Sure it'll be in PECL, just like dio, crack, yaz, and the other half
dozen or so extensions we've removed from PHP 5 ext/ and into PECL.
It's the 'given that it doesn't appear to have an active maintainer' part
that's important here. It takes a little TLC to make a PECL package
available for download.
I'm well aware of ext/xmlrpc's limitations, haven't tried the new (but
necessary) pecl/xmlrpci yet, and have the tiny issue that a bunch of my
scripts will need a complete rewrite if the old extension is simply
taken
away from PHP 5 up. I suspect I'm far from being alone in that - do we
have
figures for core extension usage, anyone?Well considering we've done it already with a number of extensions, I
don't see a big issue. Note also that I'm not hugely concerned with
when this happens (read: What version of PHP the change is made).
Although there could be a bunch of compat functions to emulate the old
xmlrpc behavior,I'm against it simply because there is nothing stopping
someone from having both extensions loaded.
That's fair enough, so long as the older version is readily available. It
becomes a problem if it isn't. The word 'replace' kind of intimates that
the original extension is effectively a goner - and if you meant 'replace in
the core', I'm unaware of a precedent for that.
- Steph
It's the 'given that it doesn't appear to have an active maintainer' part
that's important here. It takes a little TLC to make a PECL package
available for download.
I'll roll the PECL package myself.
I'm well aware of ext/xmlrpc's limitations, haven't tried the new (but
necessary) pecl/xmlrpci yet, and have the tiny issue that a bunch of my
scripts will need a complete rewrite if the old extension is simply
taken
away from PHP 5 up. I suspect I'm far from being alone in that - do we
have
figures for core extension usage, anyone?Well considering we've done it already with a number of extensions, I
don't see a big issue. Note also that I'm not hugely concerned with
when this happens (read: What version of PHP the change is made).
Although there could be a bunch of compat functions to emulate the old
xmlrpc behavior,I'm against it simply because there is nothing stopping
someone from having both extensions loaded.That's fair enough, so long as the older version is readily available. It
becomes a problem if it isn't. The word 'replace' kind of intimates that
the original extension is effectively a goner - and if you meant 'replace in
the core', I'm unaware of a precedent for that.
Yes.
Cheers,
John
On Mon, 29 Aug 2005 07:58:33 -0400
john@coggeshall.org (John Coggeshall) wrote:
It's the 'given that it doesn't appear to have an active
maintainer' part that's important here. It takes a little TLC
to make a PECL package available for download.I'll roll the PECL package myself.
Hang on, I'm really not sure it's either good or worth the effort
to do that.
Some reasons:
-
ext/xml_rpc was kept there mainly for pear, sadly was not enabled
by default which makes it pretty useless for shared hosts and
friends -
xmlrpci do not bring anything but overloading (for the client
part, server being not in cvs last time I checked) -
Webservices (xmlrpc, soap,...) should rely on smaller memory
usages and faster processing that the default libxml2 parsers
(dom and related functions), ie xmlreader and xmlwriter, in
libxml not the php extension
In my opinion, xmlrpci and xmlrpc perfectly fit in pecl from php
6 and up. Adding one is only adding more confusions.
Regards,
--Pierre
That's fair enough, so long as the older version is readily available.
It
becomes a problem if it isn't. The word 'replace' kind of intimates
that
the original extension is effectively a goner - and if you meant
'replace in
the core', I'm unaware of a precedent for that.Yes.
Yes what? :)
Cheers,
John
Yes.
Yes what? :)
'replace in core'
John