or C) is actually regarded.
=item --version=STRING
Specify a version stamp for the code routine.
=item --hidden
If this is passe, the resulting file will include a tag that tells the server
daemon to not make the routine visible through any introspection interfaces.
=item --signature=STRING [ --signature=STRING ... ]
Specify one or more signatures for the method. Signatures should be the type
names as laid out in the documentation in L, with the
elements separated by a colon. You may also separate them with spaces, if you
quote the argument. This option may be specified more than once, as some
methods may have several signatures.
=item --helptext=STRING
Specify the help text for the method as a simple string on the command line.
Not suited for terribly long help strings.
=item --helpfile=FILE
Read the help text for the method from the file specified.
=item --code=FILE
Read the actual code for the routine from the file specified. If this option is
not given, the code is read from the standard input file descriptor.
=item --output=FILE
Write the resulting XML representation to the specified file. If this option
is not given, then the output goes to the standard output file descriptor.
=item --base=NAME
This is a special, "all-in-one" option. If passed, all other options are
ignored.
The value is used as the base element for reading information from a file
named B.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:
=over 4
=item B>
Specify the name of the routine being published. If this line does not appear,
then the value of the B<--base> argument with all directory elements removed
will be used.
=item B>
Provide a version stamp for the function. If no line matching this pattern is
present, no version tag will be written.
=item B>
If present, I should be either C or C (case not important).
If it is C, then the method is marked to be hidden from any introspection
API.
=item B>
This line may appear more than once, and is treated cumulatively. Other
options override previous values if they appear more than once. The portion
following the C 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.
=item B>
Specifies the file from which to read the help text. It is not an error if
no help text is specified.
=item B>
Specifies the file from which to read the code. Code is assumed to be Perl,
and will be tagged as such in the resulting file.
=item B>
Specifies the file from which to read code, while also identifying the
language that the code is in. This allows for the creation of a B file
that includes multiple language implementations of the given method or
procedure.
=back
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 B.xpl, preserving the path information so that
the resulting file is right alongside the source files. This allows constructs
such as:
make_method --base=methods/introspection
=back
=head1 FILE FORMAT AND DTD
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 B 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:
The file C 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 CmethoddefE>, CfunctiondefE> or
CproceduredefE>. This is followed by exactly one CnameE>
container specifying the method name, an optional version stamp, an optional
hide-from-introspection flag, one or more CsignatureE> containers
specifying signatures, an optional ChelpE> container with the help
text, then the CcodeE> container with the actual program code. All
text should use entity encoding for the symbols:
& C<&> (ampersand)
E C<<> (less-than)
E 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.
=head2 The Specification of Code
This is not I<"Programming 101">, nor is it I<"Perl for the Somewhat Dim">.
The code that is passed in via one of the C<*.xpl> files gets passed to
C 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
and safe.
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 B tool will attempt to use a C 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 F<*.xpl> files to be syntax-testable
with C. You can aid this by ensuring that the code does not contain
either of the two following character sequences:
]]>
__DATA__
The first is the C 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.
=head1 EXAMPLES
The B distribution comes with a number of default methods in a
subdirectory called (cryptically enough) C. Each of these is
expressed as a set of (C<*.base>, C<*.code>, C<*.help>) files. The Makefile.PL
file configures the resulting Makefile such that these are used to create
C<*.xpl> files using this tool, and then install them.
=head1 DIAGNOSTICS
Most problems come out in the form of error messages followed by an abrupt
exit.
=head1 EXIT STATUS
The tool exits with a status of 0 upon success, and 255 otherwise.
=head1 CAVEATS
I don't much like this approach to specifying the methods, but I liked my
other ideas even less.
=head1 BUGS
Please report any bugs or feature requests to
C, or through the web interface at
L. I will be
notified, and then you'll automatically be notified of progress on
your bug as I make changes.
=head1 SUPPORT
=over 4
=item * RT: CPAN's request tracker
L
=item * AnnoCPAN: Annotated CPAN documentation
L
=item * CPAN Ratings
L
=item * Search CPAN
L
=item * Source code on GitHub
L
=back
=head1 LICENSE AND COPYRIGHT
This module and the code within are released under the terms of the Artistic
License 2.0
(http://www.opensource.org/licenses/artistic-license-2.0.php). This code may
be redistributed under either the Artistic License or the GNU Lesser General
Public License (LGPL) version 2.1
(http://www.opensource.org/licenses/lgpl-2.1.php).
=head1 SEE ALSO
L, L
=head1 CREDITS
The B standard is Copyright (c) 1998-2001, UserLand Software, Inc.
See for more information about the B
specification.
=head1 AUTHOR
Randy J. Ray
=cut