On 23 januari '09 XMLRPC was partly removed from the 1.6 trunk by Anthony and Louis. The map /xmlrp and its contents were removed but the xmlrpc library is still present in /libraries/phpxmlrpc.
I haven't come across statements about changing XMLRPC support for J1.6. In any case it isn't mentioned in "revisiting the J1.6 roadmap". Have I missed something?
Would someone please be so kind to inform me and the world about the status of XMLRPC support in J1.6.
I'm developing a component which heavenly relies on XMLRPC so this kind of worries me. Possibly it is removed because it is being reworked. So maybe i should not be worried .
Hans,
What we have done is to remove the separate XMLRPC application from the
trunk and made way for a new method of handling service requests. It is no
longer necessary to have an XMLRPC plugin group to handle XMLRPC requests
that end up proxying the logic and data structures within a component
anyway.
In your component, we'll say com_foo, designed using the MVC pattern you may
have a need to handle lots of "task-based" requests. Things like edit,
save, delete, etc. Often, when this happens it is helpful to use more than
one controller to break out code sections to smaller, more maintainable
parts. Doing this you might have the following structure:
This allows you to segment out grouped tasks into separate controllers. In
this example you can see that there is a c1.php controller and a c2.php
controller.
In 1.5, you would need to have some logic in your base foo.php to determine
which controller gets included and executed based on some request variables,
etc.
In 1.6, there is a new convention based way of achieving this behavior as
well as adding in service requests.
If you have a look at this version of the com_foo component, you will notice
a couple of extra files. In the controllers folder you now have
c1.xmlrpc.php and c1.json.php. These controllers are where the logic to
handle service calls to the c1 controller tasks would live. Lets assume
that the controller class in c1.php has only one method/task, bar.
class FooControllerC1 extends JController
{
function bar()
{
echo 'Hello World';
// Exit the application.
}
}
If you wanted to allow an XMLRPC service request for this controller, you
would simply create c1.xmlrpc.php as shown in the second folder structure
and define the methods/tasks that you want to handle:
class FooControllerC1 extends JController
{
function bar()
{
// Get an XMLRPC server object and de-serialize the request payload.
// Run method logic.
// Build XMLRPC response payload.
// Output XMLRPC response payload.
// Exit the application.
}
}
You will also notice in the second folder structure, that there is a
c1.json.php. As you can imagine, this class is pretty straightforward as
well.
class FooControllerC1 extends JController
{
function bar()
{
echo json_encode('Hello World');
// Exit the application.
}
}
As you can see, controllers can be built up to handle as many different
types of service requests as you want for whatever types of tasks you want,
within your standard component folders. It would also be trivial to turn
services on/off with simple conditional statements and component
configuration settings.
The standard way of requesting these various controllers/methods by
convention is something like:
Just to use the base c1.php controller you remove the
&protocol={SERVICE_TYPE} variable from the request URL.
In Joomla 1.6, JController has a new getInstance() method that handles this
dispatching of the correct controllers for you based on the request
variables.
We most certainly are not getting rid of the ability to utilize XMLRPC in
your components, we are simply trying to make it more consistent and
cohesive with the rest of the system.
On Tue, Apr 7, 2009 at 3:06 AM, Hans <hensi...@hotmail.com> wrote:
> On 23 januari '09 XMLRPC was partly removed from the 1.6 trunk by Anthony
> and Louis. The map /xmlrp and its contents were removed but the xmlrpc
> library is still present in /libraries/phpxmlrpc.
> I haven't come across statements about changing XMLRPC support for J1.6. In
> any case it isn't mentioned in "revisiting the J1.6 roadmap". Have I missed
> something?
> Would someone please be so kind to inform me and the world about the status
> of XMLRPC support in J1.6.
> I'm developing a component which heavenly relies on XMLRPC so this kind of
> worries me. Possibly it is removed because it is being reworked. So maybe
> i should not be worried [image: Glimlach Emoticon].
> Hans.
> BTW
> Keep up the great work you all are doing.
-- Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org
> Hans,
> What we have done is to remove the separate XMLRPC application from the
> trunk and made way for a new method of handling service requests. It is no
> longer necessary to have an XMLRPC plugin group to handle XMLRPC requests
> that end up proxying the logic and data structures within a component
> anyway.
> In your component, we'll say com_foo, designed using the MVC pattern you
> may have a need to handle lots of "task-based" requests. Things like edit,
> save, delete, etc. Often, when this happens it is helpful to use more than
> one controller to break out code sections to smaller, more maintainable
> parts. Doing this you might have the following structure:
> This allows you to segment out grouped tasks into separate controllers. In
> this example you can see that there is a c1.php controller and a c2.php
> controller.
> In 1.5, you would need to have some logic in your base foo.php to determine
> which controller gets included and executed based on some request variables,
> etc.
> In 1.6, there is a new convention based way of achieving this behavior as
> well as adding in service requests.
> If you have a look at this version of the com_foo component, you will
> notice a couple of extra files. In the controllers folder you now have
> c1.xmlrpc.php and c1.json.php. These controllers are where the logic to
> handle service calls to the c1 controller tasks would live. Lets assume
> that the controller class in c1.php has only one method/task, bar.
> class FooControllerC1 extends JController
> {
> function bar()
> {
> echo 'Hello World';
> // Exit the application.
> }
> }
> If you wanted to allow an XMLRPC service request for this controller, you
> would simply create c1.xmlrpc.php as shown in the second folder structure
> and define the methods/tasks that you want to handle:
> class FooControllerC1 extends JController
> {
> function bar()
> {
> // Get an XMLRPC server object and de-serialize the request
> payload.
> // Run method logic.
> // Build XMLRPC response payload.
> // Output XMLRPC response payload.
> // Exit the application.
> }
> }
> You will also notice in the second folder structure, that there is a
> c1.json.php. As you can imagine, this class is pretty straightforward as
> well.
> class FooControllerC1 extends JController
> {
> function bar()
> {
> echo json_encode('Hello World');
> // Exit the application.
> }
> }
> As you can see, controllers can be built up to handle as many different
> types of service requests as you want for whatever types of tasks you want,
> within your standard component folders. It would also be trivial to turn
> services on/off with simple conditional statements and component
> configuration settings.
> The standard way of requesting these various controllers/methods by
> convention is something like:
> Just to use the base c1.php controller you remove the
> &protocol={SERVICE_TYPE} variable from the request URL.
> In Joomla 1.6, JController has a new getInstance() method that handles this
> dispatching of the correct controllers for you based on the request
> variables.
> We most certainly are not getting rid of the ability to utilize XMLRPC in
> your components, we are simply trying to make it more consistent and
> cohesive with the rest of the system.
> Hope that helps,
> Louis
> On Tue, Apr 7, 2009 at 3:06 AM, Hans <hensi...@hotmail.com> wrote:
>> On 23 januari '09 XMLRPC was partly removed from the 1.6 trunk by
>> Anthony and Louis. The map /xmlrp and its contents were removed but the
>> xmlrpc library is still present in /libraries/phpxmlrpc.
>> I haven't come across statements about changing XMLRPC support for
>> J1.6. In any case it isn't mentioned in "revisiting the J1.6 roadmap". Have
>> I missed something?
>> Would someone please be so kind to inform me and the world about the
>> status of XMLRPC support in J1.6.
>> I'm developing a component which heavenly relies on XMLRPC so this kind of
>> worries me. Possibly it is removed because it is being reworked. So maybe
>> i should not be worried [image: Glimlach Emoticon].
>> Hans.
>> BTW
>> Keep up the great work you all are doing.
> --
> Development Coordinator
> Joomla! ... because open source matters.
> http://www.joomla.org
@Louis
Thank you very much for your detailed description. Glad that XML-RPC is here to stay Will have a long hard look at it when I'm reworking my component.
From: Rob Schley Sent: Thursday, April 09, 2009 12:27 AM
To: joomla-dev-cms@googlegroups.com Subject: Re: Support for XMLRPC in J1.6 ?
Can someone please put that on the Wiki?
Thanks,
Rob
On Wed, Apr 8, 2009 at 10:43 AM, Louis Landry <louis.lan...@joomla.org> wrote:
Hans,
What we have done is to remove the separate XMLRPC application from the trunk and made way for a new method of handling service requests. It is no longer necessary to have an XMLRPC plugin group to handle XMLRPC requests that end up proxying the logic and data structures within a component anyway.
In your component, we'll say com_foo, designed using the MVC pattern you may have a need to handle lots of "task-based" requests. Things like edit, save, delete, etc. Often, when this happens it is helpful to use more than one controller to break out code sections to smaller, more maintainable parts. Doing this you might have the following structure:
This allows you to segment out grouped tasks into separate controllers. In this example you can see that there is a c1.php controller and a c2.php controller.
In 1.5, you would need to have some logic in your base foo.php to determine which controller gets included and executed based on some request variables, etc.
In 1.6, there is a new convention based way of achieving this behavior as well as adding in service requests.
If you have a look at this version of the com_foo component, you will notice a couple of extra files. In the controllers folder you now have c1.xmlrpc.php and c1.json.php. These controllers are where the logic to handle service calls to the c1 controller tasks would live. Lets assume that the controller class in c1.php has only one method/task, bar.
class FooControllerC1 extends JController
{
function bar()
{
echo 'Hello World';
// Exit the application.
}
}
If you wanted to allow an XMLRPC service request for this controller, you would simply create c1.xmlrpc.php as shown in the second folder structure and define the methods/tasks that you want to handle:
class FooControllerC1 extends JController
{
function bar()
{
// Get an XMLRPC server object and de-serialize the request payload.
// Run method logic.
// Build XMLRPC response payload.
// Output XMLRPC response payload.
// Exit the application.
}
}
You will also notice in the second folder structure, that there is a c1.json.php. As you can imagine, this class is pretty straightforward as well.
class FooControllerC1 extends JController
{
function bar()
{
echo json_encode('Hello World');
// Exit the application.
}
}
As you can see, controllers can be built up to handle as many different types of service requests as you want for whatever types of tasks you want, within your standard component folders. It would also be trivial to turn services on/off with simple conditional statements and component configuration settings.
The standard way of requesting these various controllers/methods by convention is something like:
Just to use the base c1.php controller you remove the &protocol={SERVICE_TYPE} variable from the request URL.
In Joomla 1.6, JController has a new getInstance() method that handles this dispatching of the correct controllers for you based on the request variables.
We most certainly are not getting rid of the ability to utilize XMLRPC in your components, we are simply trying to make it more consistent and cohesive with the rest of the system.
Hope that helps,
Louis
On Tue, Apr 7, 2009 at 3:06 AM, Hans <hensi...@hotmail.com> wrote:
On 23 januari '09 XMLRPC was partly removed from the 1.6 trunk by Anthony and Louis. The map /xmlrp and its contents were removed but the xmlrpc library is still present in /libraries/phpxmlrpc.
I haven't come across statements about changing XMLRPC support for J1.6. In any case it isn't mentioned in "revisiting the J1.6 roadmap". Have I missed something?
Would someone please be so kind to inform me and the world about the status of XMLRPC support in J1.6.
I'm developing a component which heavenly relies on XMLRPC so this kind of worries me. Possibly it is removed because it is being reworked. So maybe i should not be worried .
Hans.
BTW
Keep up the great work you all are doing.
--
Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org
On Wed, Apr 8, 2009 at 4:18 PM, Hans <hensi...@hotmail.com> wrote:
> @Louis
> Thank you very much for your detailed description. Glad that XML-RPC is
> here to stay [image: Glimlach Emoticon]
> Will have a long hard look at it when I'm reworking my component.
> *From:* Rob Schley <rob.sch...@community.joomla.org>
> *Sent:* Thursday, April 09, 2009 12:27 AM
> *To:* joomla-dev-cms@googlegroups.com
> *Subject:* Re: Support for XMLRPC in J1.6 ?
> Can someone please put that on the Wiki?
> Thanks,
> Rob
> On Wed, Apr 8, 2009 at 10:43 AM, Louis Landry <louis.lan...@joomla.org>wrote:
>> Hans,
>> What we have done is to remove the separate XMLRPC application from the
>> trunk and made way for a new method of handling service requests. It is no
>> longer necessary to have an XMLRPC plugin group to handle XMLRPC requests
>> that end up proxying the logic and data structures within a component
>> anyway.
>> In your component, we'll say com_foo, designed using the MVC pattern you
>> may have a need to handle lots of "task-based" requests. Things like edit,
>> save, delete, etc. Often, when this happens it is helpful to use more than
>> one controller to break out code sections to smaller, more maintainable
>> parts. Doing this you might have the following structure:
>> This allows you to segment out grouped tasks into separate controllers.
>> In this example you can see that there is a c1.php controller and a c2.php
>> controller.
>> In 1.5, you would need to have some logic in your base foo.php to
>> determine which controller gets included and executed based on some request
>> variables, etc.
>> In 1.6, there is a new convention based way of achieving this behavior as
>> well as adding in service requests.
>> If you have a look at this version of the com_foo component, you will
>> notice a couple of extra files. In the controllers folder you now have
>> c1.xmlrpc.php and c1.json.php. These controllers are where the logic to
>> handle service calls to the c1 controller tasks would live. Lets assume
>> that the controller class in c1.php has only one method/task, bar.
>> class FooControllerC1 extends JController
>> {
>> function bar()
>> {
>> echo 'Hello World';
>> // Exit the application.
>> }
>> }
>> If you wanted to allow an XMLRPC service request for this controller, you
>> would simply create c1.xmlrpc.php as shown in the second folder structure
>> and define the methods/tasks that you want to handle:
>> class FooControllerC1 extends JController
>> {
>> function bar()
>> {
>> // Get an XMLRPC server object and de-serialize the request
>> payload.
>> // Run method logic.
>> // Build XMLRPC response payload.
>> // Output XMLRPC response payload.
>> // Exit the application.
>> }
>> }
>> You will also notice in the second folder structure, that there is a
>> c1.json.php. As you can imagine, this class is pretty straightforward as
>> well.
>> class FooControllerC1 extends JController
>> {
>> function bar()
>> {
>> echo json_encode('Hello World');
>> // Exit the application.
>> }
>> }
>> As you can see, controllers can be built up to handle as many different
>> types of service requests as you want for whatever types of tasks you want,
>> within your standard component folders. It would also be trivial to turn
>> services on/off with simple conditional statements and component
>> configuration settings.
>> The standard way of requesting these various controllers/methods by
>> convention is something like:
>> Just to use the base c1.php controller you remove the
>> &protocol={SERVICE_TYPE} variable from the request URL.
>> In Joomla 1.6, JController has a new getInstance() method that handles
>> this dispatching of the correct controllers for you based on the request
>> variables.
>> We most certainly are not getting rid of the ability to utilize XMLRPC in
>> your components, we are simply trying to make it more consistent and
>> cohesive with the rest of the system.
>> Hope that helps,
>> Louis
>> On Tue, Apr 7, 2009 at 3:06 AM, Hans <hensi...@hotmail.com> wrote:
>>> On 23 januari '09 XMLRPC was partly removed from the 1.6 trunk by
>>> Anthony and Louis. The map /xmlrp and its contents were removed but the
>>> xmlrpc library is still present in /libraries/phpxmlrpc.
>>> I haven't come across statements about changing XMLRPC support for
>>> J1.6. In any case it isn't mentioned in "revisiting the J1.6 roadmap". Have
>>> I missed something?
>>> Would someone please be so kind to inform me and the world about the
>>> status of XMLRPC support in J1.6.
>>> I'm developing a component which heavenly relies on XMLRPC so this kind
>>> of worries me. Possibly it is removed because it is being reworked. So
>>> maybe i should not be worried [image: Glimlach Emoticon].
>>> Hans.
>>> BTW
>>> Keep up the great work you all are doing.
>> --
>> Development Coordinator
>> Joomla! ... because open source matters.
>> http://www.joomla.org
Did you consider upgrading the phpxmlrpc library? In the trunk it is still version 2.2 from 25/02/07. At the moment the phpxmlrpc workgroup is @ 2.2.2. Indeed no big changes. Some minor optimization was done and a few bugs were handled. So it is probably save to upgrade without breaking things.
For your convienience I hereby include the changelog since v2.2
Hans.
============ phpXMLRPC changelog since 2.2. ===============================
2009-03-16 - G. Giunta (giunta.gaet...@gmail.com) thanks Tommaso Trani
* move from CVS to SVN on sf.net; file layout now is the same as in packaged lib
* xmlrpc.inc: fix php warning when receiving 'false' in a bool value
* Makefile, doc/Makefile: alter to follow new file layout
* debugger/action.php: improve code robustness when parsing system.listmethods
and system.describemethods call
* xmlrpc.inc: format floating point values using the correct decimal separator
even when php locale is set to one that uses comma (bug #2517579);
use feof() to test if socket connections are to be closed instead of the
number of bytes read (bug #2556209)
* xmlrpc.inc, xmlrps.inc: do not try to set invalid charsets as output for
xml parser, even if user set them up for internal_encoding (helps encoding
to exotic charsets, while decoding to UTF8)
* xmlrpc.inc: give more detailed curl information when DEBUG = 2; fix handling
of case where curl w. keepalive is used and one connection of many fails
* testsuite improvements: add one testcase; give feedbcak while tests are
running
* doc/makefile, doc/convert.php, doc/*.xsl: created customizations xslt to
produce a documentation more in line with the php manual, esp. with regards
to functions synopsis; added jellyfish book cover as local resource and a
screenshot of the debugger too; various updates to the manual source; added
a php script to highlight examples inside html docs
* xmlrpc.inc: micro-optimization in declaration of global vars xmlrpcerr, xmlrpcstr
From: Louis Landry Sent: Wednesday, April 08, 2009 7:43 PM
To: joomla-dev-cms@googlegroups.com Subject: Re: Support for XMLRPC in J1.6 ?
Hans,
What we have done is to remove the separate XMLRPC application from the trunk and made way for a new method of handling service requests. It is no longer necessary to have an XMLRPC plugin group to handle XMLRPC requests that end up proxying the logic and data structures within a component anyway.
In your component, we'll say com_foo, designed using the MVC pattern you may have a need to handle lots of "task-based" requests. Things like edit, save, delete, etc. Often, when this happens it is helpful to use more than one controller to break out code sections to smaller, more maintainable parts. Doing this you might have the following structure:
This allows you to segment out grouped tasks into separate controllers. In this example you can see that there is a c1.php controller and a c2.php controller.
In 1.5, you would need to have some logic in your base foo.php to determine which controller gets included and executed based on some request variables, etc.
In 1.6, there is a new convention based way of achieving this behavior as well as adding in service requests.
If you have a look at this version of the com_foo component, you will notice a couple of extra files. In the controllers folder you now have c1.xmlrpc.php and c1.json.php. These controllers are where the logic to handle service calls to the c1 controller tasks would live. Lets assume that the controller class in c1.php has only one method/task, bar.
class FooControllerC1 extends JController
{
function bar()
{
echo 'Hello World';
// Exit the application.
}
}
If you wanted to allow an XMLRPC service request for this controller, you would simply create c1.xmlrpc.php as shown in the second folder structure and define the methods/tasks that you want to handle:
class FooControllerC1 extends JController
{
function bar()
{
// Get an XMLRPC server object and de-serialize the request payload.
// Run method logic.
// Build XMLRPC response payload.
// Output XMLRPC response payload.
// Exit the application.
}
}
You will also notice in the second folder structure, that there is a c1.json.php. As you can imagine, this class is pretty straightforward as well.
class FooControllerC1 extends JController
{
function bar()
{
echo json_encode('Hello World');
// Exit the application.
}
}
As you can see, controllers can be built up to handle as many different types of service requests as you want for whatever types of tasks you want, within your standard component folders. It would also be trivial to turn services on/off with simple conditional statements and component configuration settings.
The standard way of requesting these various controllers/methods by convention is something like:
Just to use the base c1.php controller you remove the &protocol={SERVICE_TYPE} variable from the request URL.
In Joomla 1.6, JController has a new getInstance() method that handles this dispatching of the correct controllers for you based on the request variables.
We most certainly are not getting rid of the ability to utilize XMLRPC in your components, we are simply trying to make it more consistent and cohesive with the rest of the system.
Hope that helps,
Louis
On Tue, Apr 7, 2009 at 3:06 AM, Hans <hensi...@hotmail.com> wrote:
On 23 januari '09 XMLRPC was partly removed from the 1.6 trunk by Anthony and Louis. The map /xmlrp and its contents were removed but the xmlrpc library is still present in /libraries/phpxmlrpc.
I haven't come across statements about changing XMLRPC support for J1.6. In any case it isn't mentioned in "revisiting the J1.6 roadmap". Have I missed something?
Would someone please be so kind to inform me and the world about the status of XMLRPC support in J1.6.
I'm developing a component which heavenly relies on XMLRPC so this kind of worries me. Possibly it is
...
Are there any thoughts on providing a way to do introspection similar
to the way the old application had the onGetWebServices event that
could be used to get a list of all web services available on the site?
(well, XMLRPC services)
I guess all we need is to figure out where to locate this and
implement the call there. Though we would have to traverse our
directory for controllers and find their methods.
Ian
On Apr 8, 1:43 pm, Louis Landry <louis.lan...@joomla.org> wrote:
> Hans,
> What we have done is to remove the separate XMLRPC application from the
> trunk and made way for a new method of handling service requests. It is no
> longer necessary to have an XMLRPC plugin group to handle XMLRPC requests
> that end up proxying the logic and data structures within a component
> anyway.
> In your component, we'll say com_foo, designed using the MVC pattern you may
> have a need to handle lots of "task-based" requests. Things like edit,
> save, delete, etc. Often, when this happens it is helpful to use more than
> one controller to break out code sections to smaller, more maintainable
> parts. Doing this you might have the following structure:
> This allows you to segment out grouped tasks into separate controllers. In
> this example you can see that there is a c1.php controller and a c2.php
> controller.
> In 1.5, you would need to have some logic in your base foo.php to determine
> which controller gets included and executed based on some request variables,
> etc.
> In 1.6, there is a new convention based way of achieving this behavior as
> well as adding in service requests.
> If you have a look at this version of the com_foo component, you will notice
> a couple of extra files. In the controllers folder you now have
> c1.xmlrpc.php and c1.json.php. These controllers are where the logic to
> handle service calls to the c1 controller tasks would live. Lets assume
> that the controller class in c1.php has only one method/task, bar.
> class FooControllerC1 extends JController
> {
> function bar()
> {
> echo 'Hello World';
> // Exit the application.
> }
> }
> If you wanted to allow an XMLRPC service request for this controller, you
> would simply create c1.xmlrpc.php as shown in the second folder structure
> and define the methods/tasks that you want to handle:
> class FooControllerC1 extends JController
> {
> function bar()
> {
> // Get an XMLRPC server object and de-serialize the request payload.
> // Run method logic.
> // Build XMLRPC response payload.
> // Output XMLRPC response payload.
> // Exit the application.
> }
> }
> You will also notice in the second folder structure, that there is a
> c1.json.php. As you can imagine, this class is pretty straightforward as
> well.
> class FooControllerC1 extends JController
> {
> function bar()
> {
> echo json_encode('Hello World');
> // Exit the application.
> }
> }
> As you can see, controllers can be built up to handle as many different
> types of service requests as you want for whatever types of tasks you want,
> within your standard component folders. It would also be trivial to turn
> services on/off with simple conditional statements and component
> configuration settings.
> The standard way of requesting these various controllers/methods by
> convention is something like:
> Just to use the base c1.php controller you remove the
> &protocol={SERVICE_TYPE} variable from the request URL.
> In Joomla 1.6, JController has a new getInstance() method that handles this
> dispatching of the correct controllers for you based on the request
> variables.
> We most certainly are not getting rid of the ability to utilize XMLRPC in
> your components, we are simply trying to make it more consistent and
> cohesive with the rest of the system.
> Hope that helps,
> Louis
> On Tue, Apr 7, 2009 at 3:06 AM, Hans <hensi...@hotmail.com> wrote:
> > On 23 januari '09 XMLRPC was partly removed from the 1.6 trunk by Anthony
> > and Louis. The map /xmlrp and its contents were removed but the xmlrpc
> > library is still present in /libraries/phpxmlrpc.
> > I haven't come across statements about changing XMLRPC support for J1.6. In
> > any case it isn't mentioned in "revisiting the J1.6 roadmap". Have I missed
> > something?
> > Would someone please be so kind to inform me and the world about the status
> > of XMLRPC support in J1.6.
> > I'm developing a component which heavenly relies on XMLRPC so this kind of
> > worries me. Possibly it is removed because it is being reworked. So maybe
> > i should not be worried [image: Glimlach Emoticon].
> > Hans.
> > BTW
> > Keep up the great work you all are doing.
> --
> Development Coordinator
> Joomla! ... because open source matters.http://www.joomla.org
Hi Hans,
looking at the sourceforge-project of phpxmlrpc, they have a bug in
2.2.2 that wont make it work on PHP5.2.2. If you could contact them and
get a fixed version that will work in 5.2.2, make a patch and put it
into the feature patch tracker and I will put it into 1.6. :-)
> Did you consider upgrading the phpxmlrpc library? In the trunk it is
> still version 2.2 from 25/02/07.
> At the moment the phpxmlrpc workgroup is @ 2.2.2. Indeed no big
> changes. Some minor optimization was done and a few bugs were handled.
> So it is probably save to upgrade without breaking things.
> For your convienience I hereby include the changelog since v2.2
> Hans.
> ============ phpXMLRPC changelog since 2.2.
> ===============================
> * move from CVS to SVN on sf.net; file layout now is the same as in
> packaged lib
> * xmlrpc.inc: fix php warning when receiving 'false' in a bool value
> * Makefile, doc/Makefile: alter to follow new file layout
> * tagged and released as 2.2.2
> 2009-02-03 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * debugger/action.php: improve code robustness when parsing
> system.listmethods
> and system.describemethods call
> * xmlrpc.inc: format floating point values using the correct decimal
> separator
> even when php locale is set to one that uses comma (bug #2517579);
> use feof() to test if socket connections are to be closed instead of the
> number of bytes read (bug #2556209)
> 2008-10-29 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * xmlrpcs.inc: allow add_to_map server method to add docs for single
> params, too
> 2008-09-20 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * xmlrpc_wrappers.inc: added the possibility to wrap for exposure as
> xmlrpc
> methods plain php class methods, object methods and even whole classes
> * testsuite.php, server.php: added test cases for the new code
> 2008-09-07 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>) thanks Bruno Zanetti Melotti
> * xmlrpc.inc: be more tolerant in detection of charset in http
> headers (fix for bug #2058158)
> 2008-04-05 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * xmlrpc.inc: fix encoding of UTF8 chars outside of the BMP
> * xmlrpcs.inc: fix detection of zlib.output_compression (thanks xbert)
> 2008-03-06 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * tagged and released as 2.2.1
> * Makefile: improve usage on windows xp despite cmd's broken mkdir
> 2007-10-26 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>) thanks sajo_raftman
> * xmlrpc.inc: remove one warning in xmlrpc_client creator
> 2007-10-26 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * xmlrpc.inc: improve support for windows cp1252 character set (still
> commented in the code)
> 2007-09-05 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * xmlrpc.inc, xmlrps.inc: do not try to set invalid charsets as
> output for
> xml parser, even if user set them up for internal_encoding (helps
> encoding
> to exotic charsets, while decoding to UTF8)
> 2007-09-05 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * xmlrpc.inc: fix parsing of '1e+1' as valid float
> * xmlrpcs.inc: allow errorlevel 3 to work when prev. error handler
> was a static method
> * testsuite.php: fix test on setCookie()
> 2007-08-31 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * xmlrpc.inc: minor fix in cookie parsing
> 2007-07-31 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * xmlrpc.inc: Fix usage of client::setcookie() for multiple cookies
> in non-ssl mode
> 2007-07-26 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>) thanks Mark Olive
> * xmlrpc.inc: Fix for bug # 1756274 (usage of cookies in ssl mode)
> 2007-04-28 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * xmlrpc.inc: give more detailed curl information when DEBUG = 2; fix
> handling
> of case where curl w. keepalive is used and one connection of many fails
> * testsuite improvements: add one testcase; give feedbcak while tests are
> running
> 2007-04-01 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * doc/makefile, doc/custom.fo.xsl: improve pdf rendering of php
> source code
> * makefile: recover version number from source instead of having it
> hardcoded
> 2007-03-10 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * doc/makefile, doc/convert.php, doc/*.xsl: created customizations
> xslt to
> produce a documentation more in line with the php manual, esp. with
> regards
> to functions synopsis; added jellyfish book cover as local resource and a
> screenshot of the debugger too; various updates to the manual source;
> added
> a php script to highlight examples inside html docs
> 2007-03-09 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * debugger/action.php: css tweak for IE
> * added phpunit license file in the phpunit directory
> * added link to license (on sf.net site) to many files
> 2007-03-04 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * Makefile, doc/makefile: assorted improvements
> 2007-03-03 - G. Giunta (giunta.gaet...@gmail.com
> <mailto:giunta.gaet...@gmail.com>)
> * xmlrpc.inc: micro-optimization in declaration of global vars
> xmlrpcerr, xmlrpcstr
> *From:* Louis Landry <mailto:louis.lan...@joomla.org>
> *Sent:* Wednesday, April 08, 2009 7:43 PM
> *To:* joomla-dev-cms@googlegroups.com
> <mailto:joomla-dev-cms@googlegroups.com>
> *Subject:* Re: Support for XMLRPC in J1.6 ?
> Hans,
> What we have done is to remove the separate XMLRPC application from
> the trunk and made way for a new method of handling service requests.
> It is no longer necessary to have an XMLRPC plugin group to handle
> XMLRPC requests that end up proxying the logic and data structures
> within a component anyway.
> In your component, we'll say com_foo, designed using the MVC pattern
> you may have a need to handle lots of "task-based" requests. Things
> like edit, save, delete, etc. Often, when this happens it is helpful
> to use more than one controller to break out code sections to smaller,
> more maintainable parts. Doing this you might have the following
> structure:
> This allows you to segment out grouped tasks into separate
> controllers. In this example you can see that there is a c1.php
> controller and a c2.php controller.
> In 1.5, you would need to have some logic in your base foo.php to
> determine which controller gets included and executed based on some
> request variables, etc.
> In 1.6, there is a new convention based way of achieving this behavior
> as well as adding in service requests.
> If you have a look at this version of the com_foo component, you will
> notice a couple of extra files. In the controllers folder you now
> have c1.xmlrpc.php and c1.json.php. These controllers are where the
> logic to handle service calls to the c1 controller tasks would live.
> Lets assume that the controller class in c1.php has only one
> method/task, bar.
> class FooControllerC1 extends JController
> {
> function bar()
> {
> echo 'Hello World';
> // Exit the application.
> }
> }
> If you wanted to allow an XMLRPC service request for this controller,
> you would simply create c1.xmlrpc.php as shown in the second folder
> structure and define the methods/tasks that you want to handle:
> class FooControllerC1 extends JController
> {
> function bar()
> {
> // Get an XMLRPC server object and de-serialize the request
> payload.
> // Run method logic.
> // Build XMLRPC response payload.
> // Output XMLRPC response payload.
> // Exit the application.
> }
> }
> You will also notice in the second folder structure, that there is a
> c1.json.php. As you can imagine, this class is pretty straightforward
> as well.
> class FooControllerC1 extends JController
> {
> function bar()
> {
> echo json_encode('Hello World');
> // Exit the application.
> }
> }
> As you can see, controllers can be built up to handle as many
> different types of service requests as you want for whatever types of
> tasks you want, within your standard component folders. It
I examined the bug a bit and it turns out that the problem is not in the phpXmlRpc library but it's a bug in PHP 5.2.2 (see http://bugs.php.net/bug.php?id=41293).
the fix is a simple test for the php version and filling a global variable which does not contain the correct data
if (phpversion()=="5.2.2") {
$GLOBALS['HTTP_RAW_POST_DATA'] = file_get_contents("php://input");
}
But the message on the frontpage of the phpXmlRpc project has been put there for a reason. At the moment I do not have PHP 5.2.2 available. So testing is difficult. But I have sent a message to the project maintainers asking them for clarification. As soon as I get a response I will return to this list.
BTW if a new version of phpXmlRpc is published then it would be php5 only. I'm not sure if that is in accordance with minimum requirements for J1.6. If not we probably would have to stick to the current version of phpXmlRpc.
Hans.
--------------------------------------------------
From: "Hannes Papenberg" <hackwa...@googlemail.com>
Sent: Monday, May 25, 2009 9:46 AM
To: <joomla-dev-cms@googlegroups.com>
Subject: Re: Support for XMLRPC in J1.6 ?
> Hi Hans,
> looking at the sourceforge-project of phpxmlrpc, they have a bug in
> 2.2.2 that wont make it work on PHP5.2.2. If you could contact them and
> get a fixed version that will work in 5.2.2, make a patch and put it
> into the feature patch tracker and I will put it into 1.6. :-)
> Hannes
> Hans schrieb:
>> @Louis (and others involved in XMLRPC),
>> Did you consider upgrading the phpxmlrpc library? In the trunk it is
>> still version 2.2 from 25/02/07.
>> At the moment the phpxmlrpc workgroup is @ 2.2.2. Indeed no big
>> changes. Some minor optimization was done and a few bugs were handled.
>> So it is probably save to upgrade without breaking things.
>> For your convienience I hereby include the changelog since v2.2
>> Hans.
>> ============ phpXMLRPC changelog since 2.2.
>> ===============================
>> * move from CVS to SVN on sf.net; file layout now is the same as in
>> packaged lib
>> * xmlrpc.inc: fix php warning when receiving 'false' in a bool value
>> * Makefile, doc/Makefile: alter to follow new file layout
>> * tagged and released as 2.2.2
>> 2009-02-03 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * debugger/action.php: improve code robustness when parsing
>> system.listmethods
>> and system.describemethods call
>> * xmlrpc.inc: format floating point values using the correct decimal
>> separator
>> even when php locale is set to one that uses comma (bug #2517579);
>> use feof() to test if socket connections are to be closed instead of the
>> number of bytes read (bug #2556209)
>> 2008-10-29 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * xmlrpcs.inc: allow add_to_map server method to add docs for single
>> params, too
>> 2008-09-20 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * xmlrpc_wrappers.inc: added the possibility to wrap for exposure as
>> xmlrpc
>> methods plain php class methods, object methods and even whole classes
>> * testsuite.php, server.php: added test cases for the new code
>> 2008-09-07 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>) thanks Bruno Zanetti Melotti
>> * xmlrpc.inc: be more tolerant in detection of charset in http
>> headers (fix for bug #2058158)
>> 2008-04-05 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * xmlrpc.inc: fix encoding of UTF8 chars outside of the BMP
>> * xmlrpcs.inc: fix detection of zlib.output_compression (thanks xbert)
>> 2008-03-06 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * tagged and released as 2.2.1
>> * Makefile: improve usage on windows xp despite cmd's broken mkdir
>> 2007-10-26 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>) thanks sajo_raftman
>> * xmlrpc.inc: remove one warning in xmlrpc_client creator
>> 2007-10-26 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * xmlrpc.inc: improve support for windows cp1252 character set (still
>> commented in the code)
>> 2007-09-05 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * xmlrpc.inc, xmlrps.inc: do not try to set invalid charsets as
>> output for
>> xml parser, even if user set them up for internal_encoding (helps
>> encoding
>> to exotic charsets, while decoding to UTF8)
>> 2007-09-05 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * xmlrpc.inc: fix parsing of '1e+1' as valid float
>> * xmlrpcs.inc: allow errorlevel 3 to work when prev. error handler
>> was a static method
>> * testsuite.php: fix test on setCookie()
>> 2007-08-31 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * xmlrpc.inc: minor fix in cookie parsing
>> 2007-07-31 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * xmlrpc.inc: Fix usage of client::setcookie() for multiple cookies
>> in non-ssl mode
>> 2007-07-26 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>) thanks Mark Olive
>> * xmlrpc.inc: Fix for bug # 1756274 (usage of cookies in ssl mode)
>> 2007-04-28 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * xmlrpc.inc: give more detailed curl information when DEBUG = 2; fix
>> handling
>> of case where curl w. keepalive is used and one connection of many fails
>> * testsuite improvements: add one testcase; give feedbcak while tests >> are
>> running
>> 2007-04-01 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * doc/makefile, doc/custom.fo.xsl: improve pdf rendering of php
>> source code
>> * makefile: recover version number from source instead of having it
>> hardcoded
>> 2007-03-10 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * doc/makefile, doc/convert.php, doc/*.xsl: created customizations
>> xslt to
>> produce a documentation more in line with the php manual, esp. with
>> regards
>> to functions synopsis; added jellyfish book cover as local resource and >> a
>> screenshot of the debugger too; various updates to the manual source;
>> added
>> a php script to highlight examples inside html docs
>> 2007-03-09 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * debugger/action.php: css tweak for IE
>> * added phpunit license file in the phpunit directory
>> * added link to license (on sf.net site) to many files
>> 2007-03-04 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> 2007-03-03 - G. Giunta (giunta.gaet...@gmail.com
>> <mailto:giunta.gaet...@gmail.com>)
>> * xmlrpc.inc: micro-optimization in declaration of global vars
>> xmlrpcerr, xmlrpcstr
>> *From:* Louis Landry <mailto:louis.lan...@joomla.org>
>> *Sent:* Wednesday, April 08, 2009 7:43 PM
>> *To:* joomla-dev-cms@googlegroups.com
>> <mailto:joomla-dev-cms@googlegroups.com>
>> *Subject:* Re: Support for XMLRPC in J1.6 ?
>> Hans,
>> What we have done is to remove the separate XMLRPC application from
>> the trunk and made way for a new method of handling service requests.
>> It is no longer necessary to have an XMLRPC plugin group to handle
>> XMLRPC requests that end up proxying the logic and data structures
>> within a component anyway.
>> In your component, we'll say com_foo, designed using the MVC pattern
>> you may have a need to handle lots of "task-based" requests. Things
>> like edit, save, delete, etc. Often, when this happens it is helpful
>> to use more than one controller to break out code sections to smaller,
>> more maintainable parts. Doing this you might have the following
>> structure:
>> This allows you to segment out grouped tasks into separate
>> controllers. In this example you can see that there is a c1.php
>> controller and a c2.php controller.
>> In 1.5, you would need to have some logic in your base foo.php to
>> determine which controller gets included and executed based on some
>> request variables, etc.
>> In 1.6, there is a new convention based way of achieving this behavior
>> as well as adding in service requests.
> I examined the bug a bit and it turns out that the problem is not in the > phpXmlRpc library but it's a bug in PHP 5.2.2 (see > http://bugs.php.net/bug.php?id=41293).
> the fix is a simple test for the php version and filling a global variable > which does not contain the correct data
> if (phpversion()=="5.2.2") {
> $GLOBALS['HTTP_RAW_POST_DATA'] = file_get_contents("php://input");
> }
> But the message on the frontpage of the phpXmlRpc project has been put there > for a reason. At the moment I do not have PHP 5.2.2 available. So testing is > difficult. But I have sent a message to the project maintainers asking them > for clarification. As soon as I get a response I will return to this list.
> BTW if a new version of phpXmlRpc is published then it would be php5 only. > I'm not sure if that is in accordance with minimum requirements for J1.6. If > not we probably would have to stick to the current version of phpXmlRpc.
> Hans.
> --------------------------------------------------
> From: "Hannes Papenberg" <hackwa...@googlemail.com>
> Sent: Monday, May 25, 2009 9:46 AM
> To: <joomla-dev-cms@googlegroups.com>
> Subject: Re: Support for XMLRPC in J1.6 ?
>> Hi Hans,
>> looking at the sourceforge-project of phpxmlrpc, they have a bug in
>> 2.2.2 that wont make it work on PHP5.2.2. If you could contact them and
>> get a fixed version that will work in 5.2.2, make a patch and put it
>> into the feature patch tracker and I will put it into 1.6. :-)
>> Hannes
>> Hans schrieb:
>>> @Louis (and others involved in XMLRPC),
>>> Did you consider upgrading the phpxmlrpc library? In the trunk it is
>>> still version 2.2 from 25/02/07.
>>> At the moment the phpxmlrpc workgroup is @ 2.2.2. Indeed no big
>>> changes. Some minor optimization was done and a few bugs were handled.
>>> So it is probably save to upgrade without breaking things.
>>> For your convienience I hereby include the changelog since v2.2
>>> Hans.
>>> ============ phpXMLRPC changelog since 2.2.
>>> ===============================
>>> * move from CVS to SVN on sf.net; file layout now is the same as in
>>> packaged lib
>>> * xmlrpc.inc: fix php warning when receiving 'false' in a bool value
>>> * Makefile, doc/Makefile: alter to follow new file layout
>>> * tagged and released as 2.2.2
>>> 2009-02-03 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * debugger/action.php: improve code robustness when parsing
>>> system.listmethods
>>> and system.describemethods call
>>> * xmlrpc.inc: format floating point values using the correct decimal
>>> separator
>>> even when php locale is set to one that uses comma (bug #2517579);
>>> use feof() to test if socket connections are to be closed instead of the
>>> number of bytes read (bug #2556209)
>>> 2008-10-29 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * xmlrpcs.inc: allow add_to_map server method to add docs for single
>>> params, too
>>> 2008-09-20 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * xmlrpc_wrappers.inc: added the possibility to wrap for exposure as
>>> xmlrpc
>>> methods plain php class methods, object methods and even whole classes
>>> * testsuite.php, server.php: added test cases for the new code
>>> 2008-09-07 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>) thanks Bruno Zanetti Melotti
>>> * xmlrpc.inc: be more tolerant in detection of charset in http
>>> headers (fix for bug #2058158)
>>> 2008-04-05 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * xmlrpc.inc: fix encoding of UTF8 chars outside of the BMP
>>> * xmlrpcs.inc: fix detection of zlib.output_compression (thanks xbert)
>>> 2008-03-06 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * tagged and released as 2.2.1
>>> * Makefile: improve usage on windows xp despite cmd's broken mkdir
>>> 2007-10-26 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>) thanks sajo_raftman
>>> * xmlrpc.inc: remove one warning in xmlrpc_client creator
>>> 2007-10-26 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * xmlrpc.inc: improve support for windows cp1252 character set (still
>>> commented in the code)
>>> 2007-09-05 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * xmlrpc.inc, xmlrps.inc: do not try to set invalid charsets as
>>> output for
>>> xml parser, even if user set them up for internal_encoding (helps
>>> encoding
>>> to exotic charsets, while decoding to UTF8)
>>> 2007-09-05 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * xmlrpc.inc: fix parsing of '1e+1' as valid float
>>> * xmlrpcs.inc: allow errorlevel 3 to work when prev. error handler
>>> was a static method
>>> * testsuite.php: fix test on setCookie()
>>> 2007-08-31 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * xmlrpc.inc: minor fix in cookie parsing
>>> 2007-07-31 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * xmlrpc.inc: Fix usage of client::setcookie() for multiple cookies
>>> in non-ssl mode
>>> 2007-07-26 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>) thanks Mark Olive
>>> * xmlrpc.inc: Fix for bug # 1756274 (usage of cookies in ssl mode)
>>> 2007-04-28 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * xmlrpc.inc: give more detailed curl information when DEBUG = 2; fix
>>> handling
>>> of case where curl w. keepalive is used and one connection of many fails
>>> * testsuite improvements: add one testcase; give feedbcak while tests >>> are
>>> running
>>> 2007-04-01 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * doc/makefile, doc/custom.fo.xsl: improve pdf rendering of php
>>> source code
>>> * makefile: recover version number from source instead of having it
>>> hardcoded
>>> 2007-03-10 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * doc/makefile, doc/convert.php, doc/*.xsl: created customizations
>>> xslt to
>>> produce a documentation more in line with the php manual, esp. with
>>> regards
>>> to functions synopsis; added jellyfish book cover as local resource and >>> a
>>> screenshot of the debugger too; various updates to the manual source;
>>> added
>>> a php script to highlight examples inside html docs
>>> 2007-03-09 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * debugger/action.php: css tweak for IE
>>> * added phpunit license file in the phpunit directory
>>> * added link to license (on sf.net site) to many files
>>> 2007-03-04 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> 2007-03-03 - G. Giunta (giunta.gaet...@gmail.com
>>> <mailto:giunta.gaet...@gmail.com>)
>>> * xmlrpc.inc: micro-optimization in declaration of global vars
>>> xmlrpcerr, xmlrpcstr
>>> *From:* Louis Landry <mailto:louis.lan...@joomla.org>
>>> *Sent:* Wednesday, April 08, 2009 7:43 PM
>>> *To:* joomla-dev-cms@googlegroups.com
>>> <mailto:joomla-dev-cms@googlegroups.com>
>>> *Subject:* Re: Support for XMLRPC in J1.6 ?
>>> Hans,
>>> What we have done is to remove the separate XMLRPC application from
>>> the trunk and made way for a new method of handling service requests.
>>> It is no longer necessary to have an XMLRPC plugin group to handle
>>> XMLRPC requests that end up proxying the logic and data structures
>>> within a component anyway.
>>> In your component, we'll say com_foo, designed using the MVC pattern
>>> you may have a need to handle lots of "task-based" requests. Things
>>> like edit, save, delete, etc. Often, when this happens it is helpful
>>> to use more than one controller to break out code sections to smaller,
>>> more maintainable parts. Doing this you might have the following
>>> structure:
>>> This allows you to segment out grouped tasks into separate
>>> controllers. In this example you can see that there is a c1.php
>>> controller and a c2.php controller.
>>> In 1.5, you would need to have some logic in your base foo.php to
>>> determine which controller gets included and executed based on some
>>> request variables, etc.
>>> In 1.6, there is a new convention based way of achieving this behavior
>>> as well as adding in service requests.
As the current maintainer of the lib,
- I can assure you that the issue with php 5.2.2 has been fixed in
phpxmlrpc 221 and 222. So it is one more reason to upgrade from 220
- I started recently the port of the lib to php5-only. The current
version works fine, but the new one will remove old cruft that has
been in there for a long time. No release date planned yet. Any
critical bugs found (quite unlikely given the lib age and maturity)
will end up in a 223 release anyway
- I cannot restrain myself from sponsoring the busage of the sister
lib phpjsorpc to implement jsonrpc-based interfaces, too (it is found
in extras package of the phpxmlrpc download area). There is even a js
version of the lib that implements the same api client-side if needed!
On 26 May, 00:32, "Hans" <hensi...@hotmail.com> wrote:
> I examined the bug a bit and it turns out that the problem is not in the
> phpXmlRpc library but it's a bug in PHP 5.2.2 (seehttp://bugs.php.net/bug.php?id=41293).
> the fix is a simple test for the php version and filling a global variable
> which does not contain the correct data
> if (phpversion()=="5.2.2") {
> $GLOBALS['HTTP_RAW_POST_DATA'] = file_get_contents("php://input");
> }
> But the message on the frontpage of the phpXmlRpc project has been put there
> for a reason. At the moment I do not have PHP 5.2.2 available. So testing is
> difficult. But I have sent a message to the project maintainers asking them
> for clarification. As soon as I get a response I will return to this list.
> BTW if a new version of phpXmlRpc is published then it would be php5 only.
> I'm not sure if that is in accordance with minimum requirements for J1.6. If
> not we probably would have to stick to the current version of phpXmlRpc.
> Hans.
> --------------------------------------------------
> From: "Hannes Papenberg" <hackwa...@googlemail.com>
> Sent: Monday, May 25, 2009 9:46 AM
> To: <joomla-dev-cms@googlegroups.com>
> Subject: Re: Support for XMLRPC in J1.6 ?
> > Hi Hans,
> > looking at the sourceforge-project of phpxmlrpc, they have a bug in
> > 2.2.2 that wont make it work on PHP5.2.2. If you could contact them and
> > get a fixed version that will work in 5.2.2, make a patch and put it
> > into the feature patch tracker and I will put it into 1.6. :-)
> > Hannes
> > Hans schrieb:
> >> @Louis (and others involved in XMLRPC),
> >> Did you consider upgrading the phpxmlrpc library? In the trunk it is
> >> still version 2.2 from 25/02/07.
> >> At the moment the phpxmlrpc workgroup is @ 2.2.2. Indeed no big
> >> changes. Some minor optimization was done and a few bugs were handled.
> >> So it is probably save to upgrade without breaking things.
> >> For your convienience I hereby include the changelog since v2.2
> >> Hans.
> >> ============ phpXMLRPC changelog since 2.2.
> >> ===============================
> >> * move from CVS to SVN on sf.net; file layout now is the same as in
> >> packaged lib
> >> * xmlrpc.inc: fix php warning when receiving 'false' in a bool value
> >> * Makefile, doc/Makefile: alter to follow new file layout
> >> * tagged and released as 2.2.2
> >> 2009-02-03 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * debugger/action.php: improve code robustness when parsing
> >> system.listmethods
> >> and system.describemethods call
> >> * xmlrpc.inc: format floating point values using the correct decimal
> >> separator
> >> even when php locale is set to one that uses comma (bug #2517579);
> >> use feof() to test if socket connections are to be closed instead of the
> >> number of bytes read (bug #2556209)
> >> 2008-10-29 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * xmlrpcs.inc: allow add_to_map server method to add docs for single
> >> params, too
> >> 2008-09-20 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * xmlrpc_wrappers.inc: added the possibility to wrap for exposure as
> >> xmlrpc
> >> methods plain php class methods, object methods and even whole classes
> >> * testsuite.php, server.php: added test cases for the new code
> >> 2008-09-07 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>) thanks Bruno Zanetti Melotti
> >> * xmlrpc.inc: be more tolerant in detection of charset in http
> >> headers (fix for bug #2058158)
> >> 2008-04-05 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * xmlrpc.inc: fix encoding of UTF8 chars outside of the BMP
> >> * xmlrpcs.inc: fix detection of zlib.output_compression (thanks xbert)
> >> 2008-03-06 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * tagged and released as 2.2.1
> >> * Makefile: improve usage on windows xp despite cmd's broken mkdir
> >> * xmlrpc.inc: remove one warning in xmlrpc_client creator
> >> 2007-10-26 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * xmlrpc.inc: improve support for windows cp1252 character set (still
> >> commented in the code)
> >> 2007-09-05 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * xmlrpc.inc, xmlrps.inc: do not try to set invalid charsets as
> >> output for
> >> xml parser, even if user set them up for internal_encoding (helps
> >> encoding
> >> to exotic charsets, while decoding to UTF8)
> >> 2007-09-05 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * xmlrpc.inc: fix parsing of '1e+1' as valid float
> >> * xmlrpcs.inc: allow errorlevel 3 to work when prev. error handler
> >> was a static method
> >> * testsuite.php: fix test on setCookie()
> >> 2007-08-31 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * xmlrpc.inc: minor fix in cookie parsing
> >> 2007-07-31 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * xmlrpc.inc: Fix usage of client::setcookie() for multiple cookies
> >> in non-ssl mode
> >> 2007-07-26 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>) thanks Mark Olive
> >> * xmlrpc.inc: Fix for bug # 1756274 (usage of cookies in ssl mode)
> >> 2007-04-28 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * xmlrpc.inc: give more detailed curl information when DEBUG = 2; fix
> >> handling
> >> of case where curl w. keepalive is used and one connection of many fails
> >> * testsuite improvements: add one testcase; give feedbcak while tests
> >> are
> >> running
> >> 2007-04-01 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * doc/makefile, doc/custom.fo.xsl: improve pdf rendering of php
> >> source code
> >> * makefile: recover version number from source instead of having it
> >> hardcoded
> >> 2007-03-10 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * doc/makefile, doc/convert.php, doc/*.xsl: created customizations
> >> xslt to
> >> produce a documentation more in line with the php manual, esp. with
> >> regards
> >> to functions synopsis; added jellyfish book cover as local resource and
> >> a
> >> screenshot of the debugger too; various updates to the manual source;
> >> added
> >> a php script to highlight examples inside html docs
> >> 2007-03-09 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * debugger/action.php: css tweak for IE
> >> * added phpunit license file in the phpunit directory
> >> * added link to license (on sf.net site) to many files
> >> 2007-03-04 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> 2007-03-03 - G. Giunta (giunta.gaet...@gmail.com
> >> <mailto:giunta.gaet...@gmail.com>)
> >> * xmlrpc.inc: micro-optimization in declaration of global vars
> >> xmlrpcerr, xmlrpcstr
> >> *From:* Louis Landry <mailto:louis.lan...@joomla.org>
> >> *Sent:* Wednesday, April 08, 2009 7:43 PM
> >> *To:* joomla-dev-cms@googlegroups.com
> >> <mailto:joomla-dev-cms@googlegroups.com>
> >> *Subject:* Re: Support for XMLRPC in J1.6 ?
> >> Hans,
> >> What we have done is to remove the separate XMLRPC application from
> >> the trunk and made way for a new method of handling service requests.
> >> It is no longer necessary to have an XMLRPC plugin group to handle
> >> XMLRPC requests that end up proxying the logic and data structures
> >> within a component anyway.
> >> In your component, we'll say com_foo, designed using the MVC pattern
> >> you may have a need to handle lots of "task-based" requests. Things
> >> like edit, save, delete, etc. Often, when this happens it is helpful
> >> to use more than one controller to break out code sections to smaller,
> >> more maintainable parts. Doing this you might have the following
> >> structure:
