Everything

php

PHP 5.1: Does it still require ext/xmlrpc for pear?

php.internals

Jani Taskinen

21 years ago

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

Rasmus Lerdorf

21 years ago

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

21 years ago

On Sat, 27 Aug 2005, Rasmus Lerdorf wrote:

> 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

John Coggeshall

21 years ago

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

On Sun, 2005-08-28 at 04:10 +0300, Jani Taskinen wrote:

Steph

21 years ago

'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?

John Coggeshall

21 years ago

On Sun, 2005-08-28 at 16:23 +0200, Steph wrote:

> '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.

Steph

21 years ago

> On Sun, 2005-08-28 at 16:23 +0200, Steph wrote:
> > '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

John Coggeshall

21 years ago

On Mon, 2005-08-29 at 13:23 +0200, Steph 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.

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

Pierre-Alain Joye

21 years ago

On Mon, 29 Aug 2005 07:58:33 -0400
john@coggeshall.org (John Coggeshall) wrote:

> On Mon, 2005-08-29 at 13:23 +0200, Steph 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

Steph

21 years ago

> > 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?  :)

John Coggeshall

21 years ago

On Mon, 2005-08-29 at 14:43 +0200, Steph wrote:

> >
> > Yes.
>
> Yes what?  :)

'replace in core'

John