RPC::XML(3)

📦
version 0.82 · 5 versions
, in opensuse-leap 16.0

💖 RPC::XML(3) 💖

okay so bestie, welcome to the RPC::XML(3) manual page — this is the one about the RPC::XML package, and it's literally a whole set of classes for core data, message and XML handling. periodt. ✨

🌸 NAME 🌸

RPC::XML — a set of classes for core data, message and XML handling. 💅

✨ SYNOPSIS ✨

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;
}

💖 DESCRIPTION 💖

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. 👑

🫶 SUBROUTINES/METHODS 🫶

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]) ⏰

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. 🕰️

🧠 smart_encode(@args) 🧠

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: 🎀

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 shorthand 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. 👑💜

💅 CLASSES 💅

okay so the classes this module hands you come in two whole flavors: data classes and message classes. that's the vibe check. ✨

🎀 Data Classes 🎀

here's the data-class lineup, bestie. every single one gives you at least the methods listed right below. one thing to know up front: these are throw-away objects, fr — there's currently no mechanism for changing the value stored inside one of them after the constructor returns. the assumption is you just make a new object instead. periodt. 💅

so, the methods every data class has:

  • new($value) — the constructor. the value you pass in is the value that gets encapsulated in the new object. that's it, that's the whole job. 🫶
  • value — hands back the value kicking it inside the object. for array and struct objects it processes recursively, so you get the whole thing, not just a teaser.
  • as_string — returns the value as an XML-RPC fragment, with all the proper tags and everything. iconic.
  • serialize($filehandle) — sends the stringified rendition of the data to the file handle you give it. this is the moment for messages with arbitrarily-large base-64 data inside them, because you can send them without having to hold the entire message in process memory. your RAM said thank you. 😭
  • length — the length, in bytes, of the object when it's serialized into XML. the client and server classes use this to calculate message length. math girlies rise. 🧮
  • type — tells you the type of data being stored. it matches the XML-RPC specification, which means the normalized form datetime_iso8601 comes back as dateTime.iso8601. yes, the casing flip is real and yes, it's intentional. 🦋
  • is_fault — every type except the fault class returns false here. it exists so you can consistently test return values for fault status without going full detective and checking for a hash reference with specific keys defined. convenience slay.

👑 RPC::XML::int

creates an integer value. the constructor expects the integer value as an argument. simple, clean, no notes.

🍓 RPC::XML::i4

this is like the int class. important tea: services written in strictly-typed languages such as C, C++ or Java may consider the i4 and int types as distinct and different. so don't go assuming they're twins in every language, iykyk. 💀

🌸 RPC::XML::i8

this represents an 8-byte integer, and it is not officially supported by the XML-RPC specification. it's been added to accommodate services already in use that have chosen to add this extension. it's giving "the community asked nicely and we delivered". ✨

🦋 RPC::XML::double

creates a floating-point value. floating, like your attention span when someone explains XML namespaces. 💅

🎀 RPC::XML::string

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 — those get XML-escaped during object creation, and then reverted when the value method is called. balance restored. ⚖️

🌈 RPC::XML::boolean

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". so many ways to say yes and no and honestly? versatile icon behavior. 🫶

⭐ RPC::XML::datetime_iso8601

creates an instance of the XML-RPC dateTime.iso8601 type. the specification for ISO 8601 may be found elsewhere — not our problem today. no processing is done to the data.

and now for the messy part: the XML-RPC specification actually got the format of an ISO 8601 date slightly wrong. because this is what's in the published spec, this package produces dates that match the XML-RPC spec, not the ISO 8601 spec. however, it will read date-strings in proper ISO 8601 format. see "DATES AND TIMES", below. 💀 the spec fumbled but we're being respectful about it.

🙈 RPC::XML::nil

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 — and this is the sneaky part — 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. no borrowing, no swapping, no exceptions. 🙅‍♀️

🧚 RPC::XML::base64

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 without your process having a whole meltdown. in these cases, the flag (that 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 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. numbers, immaculate. 🔥

💜 RPC::XML::array

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). heads up, bestie. 🫶

🌸 RPC::XML::struct

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 — sorry to the order-enjoyers. key strings are now encoded for special XML characters, so the use of such ("<", ">", etc.) should be transparent to the user. and 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:

  • 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. 🦋

💀 RPC::XML::fault

a fault object is a special case of the struct object that checks to ensure that there are two keys: faultCode and faultString. it's the struct with trust issues and honestly? valid.

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:

  • code
  • string

both names should be self-explanatory. the values returned are Perl values, not RPC::XML class instances. keep that in mind before you start treating them like objects. 💅

💌 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. dual-purpose icons, we love to see it. 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. 👑
  • as_string — 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. don't take it personally, it's just for machines. 💀
  • serialize($filehandle) — 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. your memory stays unbothered. 🧚
  • length — returns the total size of the message in bytes, used by the client and server classes to set the Content-Length header. yes, headers need numbers. 🔥

the two message-object classes are:

🌈 RPC::XML::request

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 as_string):

  • name — the name of the remote routine that the request will call.
  • args — returns a list reference with the arguments that will be passed. no arguments will result in a reference to an empty list. an empty list is still a list, representation matters. 🫶

💖 RPC::XML::response

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):

  • value — the value the response is returning. it will be a RPC::XML data-type.
  • is_fault — 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. you love to see it. 💅

🕰️ DATES AND TIMES 🕰️

Okay so bestie, the XML-RPC spec calls date/time values ISO 8601, but the examples lowkey got the syntax slightly wrong. And because this is the published specification, we still have to produce time-stamps that conform to that format. The spec implies the only format for date/time values is:

YYYYMMDDThh:mm:ss

Here, the "T" is literal, and the rest represents elements of the date and time. But plot twist: the ISO 8601 specification does not allow this particular format, and is generally 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 that, 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 too, 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 the absence of an explicit timezone dictates UTC. iykyk 💅

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.

💀 DIAGNOSTICS 💀

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

🌈 GLOBAL VARIABLES 🌈

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:

💌 $ENCODING

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.

💌 $FORCE_STRING_ENCODING

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".

💌 $ALLOW_NIL

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".

🫶 CAVEATS 🫶

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. ngl, iconic humble origin story ✨

🐛 BUGS 🐛

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?Queue=RPC-XML>. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.

🎀 SUPPORT 🎀

Bestie, legal bit: 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>).

🧚 CREDITS 🧚

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.

🦋 SEE ALSO 🦋

RPC::XML::Client, RPC::XML::Server — go give them a look, they're literally the other main characters 💖

🌸 AUTHOR 🌸

Randy J. Ray <rjray@blackperl.com>

That's the whole page, bestie! This footer energy: built against perl v5.42.0, page date 2021-04-08. Now go make some XML-RPC magic happen 💖✨🎀

📦 where this page comes from