decode_chunked (line 3106)

decode a string that is encoded w/ "chunked" transfer encoding as defined in rfc2068 par. 19.4.6 code shamelessly stolen from nusoap library by Dietrich Ayala

• string $buffer: the string to be decoded

iso8601_decode (line 2913)

• $idate
• $utc

is_valid_charset (line 3700)

Checks if a given charset encoding is present in a list of encodings or

if it is a valid subset of any encoding in the list

• string $encoding: charset to be tested
• mixed $validlist: comma separated list of valid charsets (or array of charsets)

php_xmlrpc_decode (line 2942)

Takes an xmlrpc value in PHP xmlrpcval object format and translates it into native PHP types.

Works with xmlrpc message objects as input, too.

• author: Dan Libby ([email protected])

• xmlrpcval $xmlrpc_val
• array $options: if 'decode_php_objs' is set in the options array, xmlrpc structs can be decoded into php objects

wrap_php_function (line 3239)

Given a user-defined PHP function, create a PHP 'wrapper' function that can be exposed as xmlrpc method from an xmlrpc_server object and called from remote clients.

Since php is a typeless language, to infer types of input and output parameters, it relies on parsing the javadoc-style comment block associated with the given function. Usage of xmlrpc native types (such as datetime.dateTime.iso8601 and base64) in the @param tag is also allowed, if you need the php function to receive/send data in that particular format (note that base64 enncoding/decoding is transparently carried out by the lib, while datetime vals are passed around as strings)

Known limitations:

• requires PHP 5.0.3 +
• only works for user-defined functions, not for PHP internal functions (reflection does not support retrieving number/type of params for those)
• functions returning php objects will generate special xmlrpc responses: when the xmlrpc decoding of those responses is carried out by this same lib, using the appropriate param in php_xmlrpc_decode, the php objects will be rebuilt. In short: php objects can be serialized, too (except for their resource members), using this function. Other libs might choke on the very same xml that will be generated in this case (i.e. it has a nonstandard attribute on struct element tags)
• usage of javadoc @param tags using param names in a different order from the function prototype is not considered valid (to be fixed?)

• return: on error, or an array containing the name of the new php function, its signature and docs, to be used in the server dispatch map
• todo: decide how to deal with params passed by ref: bomb out or allow?
• todo: finish using javadoc info to build method sig if all params are named but out of order
• todo: add a check for params of 'resource' type
• todo: add some trigger_errors when returning false?
• todo: what to do when the PHP function returns NULL? we are currently returning bogus responses!!!

• string $funcname: the name of the PHP user function to be exposed as xmlrpc method; array($obj, 'methodname') might be ok too, in the future...
• $newfuncname

xmlrpc_cd (line 676)

• $parser
• $data

xmlrpc_ee (line 478)

• $parser
• $name
• $rebuild_xmlrpcvals

xmlrpc_encode_entitites (line 260)

Convert a string to the correct XML representation in a target charset

To help correct communication of non-ascii chars inside strings, regardless of the charset used when sending requests, parsing them, sending responses and parsing responses, an option is to convert all non-ascii chars present in the message into their equivalent 'charset entity'. Charset entities enumerated this way are independent of the charset encoding used to transmit them, and all XML parsers are bound to understand them. Note that in the std case we are not sending a charset encoding mime type along with http headers, so we are bound by RFC 3023 to emit strict us-ascii.

• todo: do a bit of basic benchmarking (strtr vs. str_replace)
• todo: make usage of iconv() or recode_string() or mb_string() where available

• $data
• $src_encoding
• $dest_encoding