RPC::XML - A set of classes for core data, message and XML handling |
RPC::XML - A set of classes for core data, message and XML handling
use RPC::XML;
$req = RPC::XML::request->new('fetch_prime_factors', RPC::XML::int->new(985_120_528)); ... $resp = RPC::XML::ParserFactory->new()->parse(STREAM); if (ref($resp)) { return $resp->value->value; } else { 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
:
time2iso8601([$time])
$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.
smart_encode(@args)
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
:
RPC_BOOLEAN RPC_INT RPC_I4 RPC_I8 RPC_DOUBLE RPC_DATETIME_ISO8601 RPC_BASE64 RPC_STRING RPC_NIL
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 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, instead.
The common methods to all data classes are:
new($value)
array
and
struct
objects.
serialize($filehandle)
datetime_iso8601
comes back
as dateTime.iso8601
.
The classes themselves are:
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 different.
<
,
>
and &
characters, which are XML-escaped during object creation,
and then reverted when the value
method is called.
0
, no
, false
, 1
, yes
, true
.
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.
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 data-types.
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 operations.
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.
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).
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.
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.
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:
smart_encode
routine
described earlier.
serialize($filehandle)
The two message-object classes are:
new
and as_string
):
new
and
as_string
):
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:
YYYYMMDDThh:mm:ss
(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:
\d\d\d\d-?\d\d-?\d\dT?\d\d:\d\d:\d\d([.,]\d+)?(Z|[-+]\d\d:\d\d)?
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
RPC::XML:
us-ascii
, but may be set to any value recognized
by XML parsers.
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
.
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 rt.cpan.org
, or through the web interface at
http://rt.cpan.org/NoAuth/ReportBug.html. I will be
notified, and then you'll automatically be notified of progress on
your bug as I make changes.
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 (http://www.opensource.org/licenses/artistic-license-2.0.php) or the GNU LGPL 2.1 (http://www.opensource.org/licenses/lgpl-2.1.php).
The XML-RPC standard is Copyright (c) 1998-2001, UserLand Software, Inc. See http://www.xmlrpc.com for more information about the XML-RPC specification.
RPC::XML::Client, RPC::XML::Server
Randy J. Ray <rjray@blackperl.com>
RPC::XML - A set of classes for core data, message and XML handling |