Provided by: librpc-xml-perl_0.80-2_all bug


       RPC::XML - A set of classes for core data, message and XML handling


           use RPC::XML;

           $req = RPC::XML::request->new('fetch_prime_factors',
           $resp = RPC::XML::ParserFactory->new()->parse(STREAM);
           if (ref($resp))
               return $resp->value->value;
               die $resp;


       The RPC::XML package is an implementation of the XML-RPC standard. The package as a whole
       provides classes for data, for clients, for servers and for parsers (based on the
       XML::Parser and XML::LibXML packages from CPAN).

       This module provides a set of classes for creating values to pass to the constructors for
       requests and responses. These are lightweight objects, most of which are implemented as
       blessed scalar references so as to associate specific type information with the value.
       Classes are also provided for requests, responses and faults (errors).

       This module does not actually provide any transport implementation or server basis. For
       these, see RPC::XML::Client and RPC::XML::Server, respectively.


       At present, two subroutines are available for import. They must be explicitly imported as
       part of the "use" statement, or with a direct call to "import":

           Convert the integer time value in $time (which defaults to calling the built-in "time"
           if not present) to a (pseudo) ISO 8601 string in the UTC time zone. This is a
           convenience function for occassions when the return value needs to be of the
           dateTime.iso8601 type, but the value on hand is the return from the "time" built-in.
           Note that the format of this string is not strictly compliant with ISO 8601 due to the
           way the dateTime.iso8601 data-type was defined in the specification. See "DATES AND
           TIMES", below.

           Converts the passed-in arguments to datatype objects. Any that are already encoded as
           such are passed through unchanged. The routine is called recursively on hash and array
           references. Note that this routine can only deduce a certain degree of detail about
           the values passed. Boolean values will be wrongly encoded as integers. Pretty much
           anything not specifically recognizable will get encoded as a string object. Thus, for
           types such as "fault", the ISO time value, base-64 data, etc., the program must still
           explicitly encode it.  However, this routine will hopefully simplify things a little
           bit for a majority of the usage cases.

           If an argument is a blessed reference (an object), smart_encode will generally treat
           it as a non-blessed reference of the underlying type. That is, objects based on hash
           references will be encoded as if they are unblessed hash references (becoming
           RPC::XML::struct objects), objects based on array references are encoded as array
           references (RPC::XML::array), etc.  Only hash references, array references and scalar
           references are treated in this fashion; any other blessed references cannot be down-
           graded and will cause an exception to be thrown.

           The exception to this are objects of the DateTime class: this package does not utilize
           DateTime directly, but if you pass in a reference to an existing object of that class,
           it is properly converted to an object of the RPC::XML::datetime_iso8601 class.

       In addition to these, the following "helper" functions are also available. They may be
       imported explicitly, or all may be imported via the tag ":types":


       Each creates a data object of the appropriate type from a single value (or, in the case of
       RPC_NIL, from no value). They are merely short- hand for calling the constructors of the
       data classes directly.

       All of the above (helpers and the first two functions) may be imported via the tag ":all".


       The classes provided by this module are broken into two groups: data classes and message

   Data Classes
       The following data classes are provided by this library. Each of these provide at least
       the set of methods below. Note that these classes are designed to create throw-away
       objects. There is currently no mechanism for changing the value stored within one of these
       object after the constructor returns. It is assumed that a new object would be created,

       The common methods to all data classes are:

           Constructor. The value passed in is the value to be encapsulated in the new object.

           Returns the value kept in the object. Processes recursively for "array" and "struct"

           Returns the value as a XML-RPC fragment, with the proper tags, etc.

           Send the stringified rendition of the data to the given file handle. This allows
           messages with arbitrarily-large base-64 data within them to be sent without having to
           hold the entire message within process memory.

           Returns the length, in bytes, of the object when serialized into XML. This is used by
           the client and server classes to calculate message length.

           Returns the type of data being stored in an object. The type matches the XML-RPC
           specification, so the normalized form "datetime_iso8601" comes back as

           All types except the fault class return false for this. This is to allow consistent
           testing of return values for fault status, without checking for a hash reference with
           specific keys defined.

       The classes themselves are:

           Creates an integer value. Constructor expects the integer value as an argument.

           This is like the "int" class. Note that services written in strictly-typed languages
           such as C, C++ or Java may consider the "i4" and "int" types as distinct and

           This represents an 8-byte integer, and is not officially supported by the XML-RPC
           specification. This has been added to accommodate services already in use that have
           chosen to add this extension.

           Creates a floating-point value.

           Creates an arbitrary string. No special encoding is done to the string (aside from XML
           document encoding, covered later) with the exception of the "<", ">" and "&"
           characters, which are XML-escaped during object creation, and then reverted when the
           "value" method is called.

           Creates a boolean value. The value returned will always be either of 1 or 0, for true
           or false, respectively. When calling the constructor, the program may specify any of:
           0, "no", "false", 1, "yes", "true".

           Creates an instance of the XML-RPC "dateTime.iso8601" type. The specification for ISO
           8601 may be found elsewhere. No processing is done to the data. Note that the XML-RPC
           specification actually got the format of an ISO 8601 date slightly wrong. Because this
           is what is in the published spec, this package produces dates that match the XML-RPC
           spec, not the the ISO 8601 spec. However, it will read date-strings in proper ISO 8601
           format. See "DATES AND TIMES", below.

           Creates a "nil" value. The value returned will always be undef. No value should be
           passed when calling the constructor.

           Note that nil is an extension to XML-RPC, which is not supported by all
           implementations. $RPC::XML::ALLOW_NIL must be set to a non-false value before objects
           of this type can be constructed. See "GLOBAL VARIABLES". However, even if
           $RPC::XML::ALLOW_NIL is set to a false value, the parsers will recognize the "<nil />"
           tag and construct an object.

           In practice, this type is only useful to denote the equivalent of a "void" return
           value from a function. The type itself is not interchangeable with any of the other

           Creates an object that encapsulates a chunk of data that will be treated as base-64
           for transport purposes. The value may be passed in as either a string or as a scalar
           reference. Additionally, a second (optional) parameter may be passed, that if true
           identifies the data as already base-64 encoded. If so, the data is decoded before
           storage. The "value" method returns decoded data, and the "as_string" method encodes
           it before stringification.

           Alternately, the constructor may be given an open filehandle argument instead of
           direct data. When this is the case, the data is never read into memory in its
           entirety, unless the "value" or "as_string" methods are called. This allows the
           manipulation of arbitrarily-large Base-64-encoded data chunks. In these cases, the
           flag (optional second argument) is still relevant, but the data is not pre-decoded if
           it currently exists in an encoded form. It is only decoded as needed. Note that the
           filehandle passed must be open for reading, at least. It will not be written to, but
           it will be read from. The position within the file will be preserved between

           Because of this, this class supports a special method called "to_file", that takes one
           argument. The argument may be either an open, writable filehandle or a string. If it
           is a string, "to_file" will attempt to open it as a file and write the decoded data to
           it. If the argument is a an open filehandle, the data will be written to it without
           any pre- or post-adjustment of the handle position (nor will it be closed upon
           completion). This differs from the "serialize" method in that it always writes the
           decoded data (where the other always writes encoded data), and in that the XML opening
           and closing tags are not written. The return value of "to_file" is the size of the
           data written in bytes.

           Creates an array object. The constructor takes zero or more data-type instances as
           arguments, which are inserted into the array in the order specified. "value" returns
           an array reference of native Perl types. If a non-null value is passed as an argument
           to "value()", then the array reference will contain datatype objects (a shallow rather
           than deep copy).

           Creates a struct object, the analogy of a hash table in Perl. The keys are ordinary
           strings, and the values must all be data-type objects. The "value" method returns a
           hash table reference, with native Perl types in the values.  Key order is not
           preserved. Key strings are now encoded for special XML characters, so the use of such
           ("<", ">", etc.) should be transparent to the user. If a non-null value is passed as
           an argument to "value()", then the hash reference will contain the datatype objects
           rather than native Perl data (a shallow vs. deep copy, as with the array type above).

           When creating RPC::XML::struct objects, there are two ways to pass the content in for
           the new object: Either an existing hash reference may be passed, or a series of
           key/value pairs may be passed. If a reference is passed, the existing data is copied
           (the reference is not re-blessed), with the values encoded into new objects as needed.

           A fault object is a special case of the struct object that checks to ensure that there
           are two keys, "faultCode" and "faultString".

           As a matter of convenience, since the contents of a RPC::XML::fault structure are
           specifically defined, the constructor may be called with exactly two arguments, the
           first of which will be taken as the code, and the second as the string. They will be
           converted to RPC::XML types automatically and stored by the pre-defined key names.

           Also as a matter of convenience, the fault class provides the following accessor
           methods for directly retrieving the integer code and error string from a fault object:


           Both names should be self-explanatory. The values returned are Perl values, not
           RPC::XML class instances.

   Message Classes
       The message classes are used both for constructing messages for outgoing communication as
       well as representing the parsed contents of a received message. Both implement the
       following methods:

       new This is the constructor method for the two message classes. The response class may
           have only a single value (as a response is currently limited to a single return
           value), and requests may have as many arguments as appropriate. In both cases, the
           arguments are passed to the exported "smart_encode" routine described earlier.

           Returns the message object expressed as an XML document. The document will be lacking
           in linebreaks and indention, as it is not targeted for human reading.

           Serialize the message to the given file-handle. This avoids creating the entire XML
           message within memory, which may be relevant if there is especially-large Base-64 data
           within the message.

           Returns the total size of the message in bytes, used by the client and server classes
           to set the Content-Length header.

       The two message-object classes are:

           This creates a request object. A request object expects the first argument to be the
           name of the remote routine being called, and all remaining arguments are the arguments
           to that routine. Request objects have the following methods (besides "new" and

               The name of the remote routine that the request will call.

               Returns a list reference with the arguments that will be passed. No arguments will
               result in a reference to an empty list.

           The response object is much like the request object in most ways. It may take only one
           argument, as that is all the specification allows for in a response. Responses have
           the following methods (in addition to "new" and "as_string"):

               The value the response is returning. It will be a RPC::XML data-type.

               A boolean test whether or not the response is signalling a fault. This is the same
               as taking the "value" method return value and testing it, but is provided for
               clarity and simplicity.


       The XML-RPC specification refers to the date/time values as ISO 8601, but unfortunately
       got the syntax slightly wrong in the examples. However, since this is the published
       specification it is necessary to produce time-stamps that conform to this format. The
       specification implies that the only format for date/time values is:


       (Here, the "T" is literal, the rest represent elements of the date and time.)  However,
       the ISO 8601 specification does not allow this particular format, and in generally is
       considerably more flexible than this.  Yet there are implementations of the XML-RPC
       standard in other languages that rely on a strict interpretation of this format.

       To accommodate this, the RPC::XML package only produces dateTime.iso8601 values in the
       format given in the spec, with the possible addition of timezone information if the string
       used to create a RPC::XML::datetime_iso8601 instance included a timezone offset. The
       string passed in to the constructor for that class must match:


       This pattern is also used by smart_encode to distinguish a date/time string from a regular
       string. Note that the "T" is optional here, as it is in the ISO 8601 spec. The timezone is
       optional, and if it is not given then UTC is assumed. The XML-RPC specification says not
       to assume anything about the timezone in the absence of one, but the format of ISO 8601
       declares that that absence of an explicit timezone dictates UTC.

       If you have DateTime::Format::ISO8601 installed, then RPC::XML::datetime_iso8601 will fall
       back on it to try and parse any input strings that do not match the above pattern. If the
       string cannot be parsed by the DateTime::Format::ISO8601 module, then the constructor
       returns undef and $RPC::XML::ERROR is set.


       All constructors (in all data classes) return "undef" upon failure, with the error message
       available in the package-global variable $RPC::XML::ERROR.


       The following global variables may be changed to control certain behavior of the library.
       All variables listed below may be imported into the application namespace when you "use"

           This variable controls the character-set encoding reported in outgoing XML messages.
           It defaults to "us-ascii", but may be set to any value recognized by XML parsers.

           By default, "smart_encode" uses heuristics to determine what encoding is required for
           a data type. For example, 123 would be encoded as "int", where 3.14 would be encoded
           as "double". In some situations it may be handy to turn off all these heuristics, and
           force encoding of "string" on all data types encountered during encoding. Setting this
           flag to "true" will do just that.

           Defaults to "false".

           By default, the XML-RPC "nil" extension is not supported. Set this to a non-false
           value to allow use of nil values. Data objects that are "nil" are represented as undef
           by Perl. See "The nil Datatype".


       This began as a reference implementation in which clarity of process and readability of
       the code took precedence over general efficiency. It is now being maintained as production
       code, but may still have parts that could be written more efficiently.


       Please report any bugs or feature requests to "bug-rpc-xml at", or through the
       web interface at <>. I will be
       notified, and then you'll automatically be notified of progress on your bug as I make


       ·   RT: CPAN's request tracker


       ·   AnnoCPAN: Annotated CPAN documentation


       ·   CPAN Ratings


       ·   Search CPAN


       ·   MetaCPAN


       ·   Source code on GitHub



       This file and the code within are copyright (c) 2011 by Randy J. Ray.

       Copying and distribution are permitted under the terms of the Artistic License 2.0
       (<>) or the GNU LGPL 2.1


       The XML-RPC standard is Copyright (c) 1998-2001, UserLand Software, Inc.  See
       <> for more information about the XML-RPC specification.


       RPC::XML::Client, RPC::XML::Server


       Randy J. Ray <>