make_method - Turn Perl code into an XML description for RPC::XML::Server
make_method --name=system.identification --helptext='System ID string' --signature=string --code=ident.pl --output=ident.xpl
This is a simple tool to create the XML descriptive files for specifying methods to be published by an RPC::XML::Server-based server.
If a server is written such that the methods it exports (or publishes) are a part of the running code, then there is no need for this tool. However, in cases where the server may be separate and distinct from the code (such as an Apache-based RPC server), specifying the routines and filling in the supporting information can be cumbersome.
One solution that the RPC::XML::Server package offers is the means to load publishable code from an external file. The file is in a simple XML dialect that clearly delinates the externally-visible name, the method signatures, the help text and the code itself. These files may be created manually, or this tool may be used as an aide.
The tool recognizes the following options:
p) is actually regarded.
The value is used as the base element for reading information from a file named BASE.base. This file will contain specification of the name, version, hidden status, signatures and other method information. Each line of the file should look like one of the following:
no(case not important). If it is
yes, then the method is marked to be hidden from any introspection API.
Signature:part is taken to be a published signature for the method, with elements separated by whitespace. Each method must have at least one signature, so a lack of any will cause an error.
Any other lines than the above patterns are ignored.
If no code has been read, then the tool will exit with an error message.
The output is written to BASE.xpl, preserving the path information so that the resulting file is right alongside the source files. This allows constructs such as:
The file format for these published routines is a very simple XML dialect. This is less due to XML being an ideal format than it is the availability of the parser, given that the RPC::XML::Server class will already have the parser code in core. Writing a completely new format would not have gained anything.
The Document Type Declaration for the format can be summarized by:
<!ELEMENT proceduredef (name, version?, hidden?, signature+, help?, code)> <!ELEMENT methoddef (name, version?, hidden?, signature+, help?, code)> <!ELEMENT functiondef (name, version?, hidden?, signature+, help?, code)> <!ELEMENT name (#PCDATA)> <!ELEMENT version (#PCDATA)> <!ELEMENT hidden EMPTY> <!ELEMENT signature (#PCDATA)> <!ELEMENT help (#PCDATA)> <!ELEMENT code (#PCDATA)> <!ATTLIST code language (#PCDATA)>
rpc-method.dtd that comes with the distribution has some
commentary in addition to the actual specification.
A file is (for now) limited to one definition. This is started by the one of
the opening tags
<proceduredef>. This is followed by exactly one
container specifying the method name, an optional version stamp, an optional
hide-from-introspection flag, one or more
specifying signatures, an optional
<help> container with the help
text, then the
<code> container with the actual program code. All
text should use entity encoding for the symbols:
& C<&> (ampersand) E<lt> C<<> (less-than) E<gt> C<>> (greater-than)
The parsing process within the server class will decode the entities. To make things easier, the tool scans all text elements and encodes the above entities before writing the file.
This is not ``Programming 101'', nor is it ``Perl for the Somewhat Dim''.
The code that is passed in via one of the
*.xpl files gets passed to
eval with next to no modification (see below). Thus, badly-written or
malicious code can very well wreak havoc on your server. This is not the fault
of the server code. The price of the flexibility this system offers is the
responsibility on the part of the developer to ensure that the code is tested
Code itself is treated as verbatim as possible. Some edits may occur on the
server-side, as it make the code suitable for creating an anonymous subroutine
from. The make_method tool will attempt to use a
CDATA section to embed
the code within the XML document, so that there is no need to encode entities
or such. This allows for the resulting *.xpl files to be syntax-testable
perl -cx. You can aid this by ensuring that the code does not contain
either of the two following character sequences:
The first is the
CDATA terminator. If it occurs naturally in the code, it
would trigger the end-of-section in the parser. The second is the familiar
Perl token, which is inserted so that the remainder of the XML document does
not clutter up the Perl parser.
The RPC::XML distribution comes with a number of default methods in a
subdirectory called (cryptically enough)
methods. Each of these is
expressed as a set of (
*.help) files. The Makefile.PL
file configures the resulting Makefile such that these are used to create
*.xpl files using this tool, and then install them.
Most problems come out in the form of error messages followed by an abrupt exit.
I don't much like this approach to specifying the methods, but I liked my other ideas even less.
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.
This module is licensed under the terms of the Artistic License that covers Perl itself. See <http://language.perl.com/misc/Artistic.html> for the license itself.
the RPC::XML manpage, the RPC::XML::Server manpage
Randy J. Ray <firstname.lastname@example.org>