Allow base64/binary values to support binary data

[temistokles]

Usage e.g.:

php_xmlrpc_encode(file_get_contents(...), ['base64'])
php_xmlrpc_encode(file_get_contents(...), ['binary'])

[gggeek]

Interesting, but I am not 100% convinced by the API change that this introduces.

Let me explain:

a) what is the added value ?

• you can currently create a binary xmlrpcValue out of a string quite easily, eg:
  new PhpXmlRpc\Value(file_get_contents(...), 'base64')
• in case, for any reason, you want to wrap this in a php_xmlrpc_encode() call, you can, and you get back the same value, eg:
  php_xmlrpc_encode(new PhpXmlRpc\Value(file_get_contents(...), 'base64'))

b) what kind of API design does this change suggest?

Currently the php_xmlrpc_encode() call:

• is based on automatic type analysis
• it only allows options to force specific type encoding where automatic type analysis is impossible
• always passes the given options recursively down the chain

If you allow the $options parameter to be used to specify the desired xmlrpc-type for the top-level php value passed in:

1. for coherence, you should allow every scalar php value to be cast to base64, not only strings
2. for coherence, you should allow casting the php value to other xmlrpc types as well besides base64
3. you break the rule that options get passed down the encoding chain (as there is no way to specify eg. that element 3 has to be converted as base64, if top-level php value is an array)

Maybe we could make a small tweak to make it possible to achieve what you desire, while keeping more in line with the current API by simply renaming the option to 'strings_as_base64' ?

[gggeek]

ps $xmlrpcBinary ?

[glensc]

yea, I use new PhpXmlRpc\Value(file_get_contents(...), 'base64') and it's fine:

https://github.com/eventum/rpc/blob/v4.3.0/src/XmlRpcClient.php#L82-L92