Thanks for the response Gaetano.

Using array to hold all the parameters as a single parameter is fine and
easy. My potential problem is the array content is undefined until at
runtime. It could be array of arrays, array of struct, array of scalars.
And for array of arrays/struct, it could be nested to contain more in the
worst cases. Obviously array of scalars is the easiest case, I'd just like
to be able to accommodate the more complex corner cases.

Per the PHP XML-RPC docs, in all cases, whether the xmlrpcval is array,
struct, or scalar, they're all of xmlrpcval types (within an array or
struct, if not a scalar by itself). So in the worst case, I'd have to
traverse the array tree to parse out all the arrays/structs to individual
scalar elements and return them back as scalarVal() for use by PHP as
native types. Just wondering what might be optimal ways to do this kind of

On Sun, Jun 16, 2013 at 1:49 PM, Gaetano Giunta <>wrote:

>  Nice to see someone still using phpxmlrpc. Old tech never dies! :-)
> On a more serious note:
> - the phpxmlrpc lib has functions which do recursive encoding/decoding.
> they are even in the manual ;-)
> - the simplest way to be able to serve calls with unknown number of
> parameters is to actually only use 1 parameter, of type "array". In the
> array then the elements will be the real parameters for the actual call on
> the php side. Of course you loose the param/type validation done for you by
> the lib, and might have to rewrite some on your own
> - if you feel adventurous, with some introspection magic you could even
> use a struct as top-level param and allow named-parameters over xmlrpc
> become positional-parameters for the php calls. iirc there is some sample
> code in the lib doing that - used by the debugger
> - the main limitation to this scheme is that you are bound not to pass
> around php objects but only php arrays/hashes. This is generally a good
> idea, security-wise
> - if you use php_xmlrpc on both sides of the tunnel, there even is an
> option for the phpxmlrpc_encode and _decode calls which allows embedding in
> the produced xml some slightly-out-of-band information.
> This allows the lib to tell apart php hashes from php objects. You will
> then be able to basically map ANY php function to its remote counterpart -
> except for the parameters which reference resources (eg a db connection can
> not be serialized across the net) or the objects with circular references
> (take care!)
> Do not hesitate to come back if there's anything I said which is not
> crystal clear
> bye
> Gaetano
> David Luu wrote:
>  Hello,
>  Don't know if anyone has asked this before, since the mailing list
> archive spans a long time, it's just easier for me to re-ask if asked
> before.
>  I'm working on a XML-RPC service that reflects any given PHP class. One
> XML-RPC method takes any number of arguments from the XML-RPC request/call.
>  In the XML-RPC method, I then store all the arguments into a PHP array
> of xmlrpcvals, via iterating over xmlrpcmsg->getParam(n) for the total # of
> params based on getNumParams().
>  I would then like to dynamically/abstractly handle converting each
> element of that xmlrpcval array into its PHP object equivalent, where the
> element may be a scalar, array, or struct (generally scalar or array). And
> that array may contain yet more scalars, arrays, or structs (though for
> simple case most likely scalars).
>  How might I recursively and/or iteratively parse the xmlrpcval array
> into it's PHP equivalent in a way that handles all cases? Since we don't
> know until runtime (i.e. when XML-RPC call is made) what the exact
> arguments are (type and number of them).
>  Has anyone done something similar before? I've done similar for other
> language platforms but those libraries did more implicit conversion
> handling for me, so I didn't have to go into this level of detail as with
> this PHP library.
>  I'm planning to try to work something out when I have time, and in the
> meantime, handle the simple case for now where the array will always be of
> scalars (not array within array), and ignore structs. And wanted to see
> what feedback/tips I can get from the community, hence this email.
>  Regards,
> David
> _______________________________________________
> phpxmlrpc mailing 
> listphpxmlrpc@lists.usefulinc.com
> _______________________________________________
> phpxmlrpc mailing list
phpxmlrpc mailing list

Reply via email to