anchor.diff:  
   * Convert xml-rpc boolean values into native php values instead of 0 and 1
   
  -* Force the ++$$php_xmlrpc_encode$$++ function to properly encode numerically indexed php arrays into xml-rpc arrays
  +* Force the `php_xmlrpc_encode` function to properly encode numerically indexed php arrays into xml-rpc arrays
       (numerically indexed php arrays always start with a key of 0 and increment keys by values of 1)
   
  -* Prevent the ++$$php_xmlrpc_encode$$++ function from further re-encoding any objects of class ++xmlrpcval++ that
  +* Prevent the `php_xmlrpc_encode` function from further re-encoding any objects of class ++xmlrpcval++ that
       are passed to it. This allows to call the function with arguments consisting of mixed php values / xmlrpcval objects
   
  -* Allow a server to NOT respond to system.* method calls (setting the ++$$$server->allow_system_funcs$$++ property).
  +* Allow a server to NOT respond to system.* method calls (setting the `$server->allow_system_funcs` property).
   
   * Implement a new xmlrpcval method to determine if a value of type struct has a member of a given name without having to
  -    loop trough all members: ++xmlrpcval::structMemExists()++
  -
  -* Expand methods ++xmlrpcval::addArray++, ++addScalar++ and ++addStruct++ allowing extra php values to be added to
  +    loop trough all members: `xmlrpcval::structMemExists()`
  +
  +* Expand methods `xmlrpcval::addArray`, `addScalar` and `addStruct` allowing extra php values to be added to
       xmlrpcval objects already formed.
   
  -* Let the ++$$xmlrpc_client::send$$++ method accept an XML string for sending instead of an xmlrpcmsg object, to
  +* Let the `xmlrpc_client::send` method accept an XML string for sending instead of an xmlrpcmsg object, to
       facilitate debugging and integration with the php native xmlrpc extension
   
  -* Extend the ++$$php_xmlrpc_encode$$++ and ++$$php_xmlrpc_decode$$++ functions to allow serialization and rebuilding of
  +* Extend the `php_xmlrpc_encode` and `php_xmlrpc_decode` functions to allow serialization and rebuilding of
       PHP objects. To successfully rebuild a serialized object, the object class must be defined in the deserializing end
       of the transfer. Note that object members of type resource will be deserialized as NULL values.
   +
  
positive.code: * The debugger can now generate code that wraps a remote method into a php function (works for jsonrpc, too); it also
      has better support for being activated via a single GET call (e.g. for integration into other tools)
  
  * Stricter parsing of incoming xmlrpc messages: two more invalid cases are now detected (double ++data++ element inside
      ++array++ and ++struct++/++array++ after scalar inside ++value++ element)
  
  * More logging of errors in a lot of situations
  
  
negative.code:     which, strictly speaking, breaks the xml-rpc spec. Other xmlrpc implementations are supposed to ignore such an
      attribute (unless they implement a brain-dead custom xml parser...), so it should be safe enabling it in
      heterogeneous environments. The activation of this feature is done by usage of an option passed as second parameter
      to both `php_xmlrpc_encode` and `php_xmlrpc_decode`.
  
  * Extend the `php_xmlrpc_encode` function to allow automatic serialization of iso8601-conforming php strings as
      datetime.iso8601 xmlrpcvals, by usage of an optional parameter
  
  * Added an automatic stub code generator for converting xmlrpc methods to php functions and vice-versa.
  +
  This is done via two new functions: `wrap_php_function` and `wrap_xmlrpc_method`, and has many caveats,
      with php being a typeless language and all...
  
  * Allow object methods to be used in server dispatch map
  
  * Added a complete debugger solution, in the __debugger__ folder
  
  * Added configurable server-side debug messages, controlled by the new method `xmlrpc_server::SetDebug()`.
      At level 0, no debug messages are sent to the client; level 1 is the same as the old behaviour; at level 2 a lot
      more info is echoed back to the client, regarding the received call; at level 3 all warnings raised during server
      processing are trapped (this prevents breaking the xml to be echoed back to the client) and added to the debug info
  