frontier::responder(3pm) [debian man page]

Frontier::Responder(3pm)				User Contributed Perl Documentation				  Frontier::Responder(3pm)

NAME

       Frontier::Responder - Create XML-RPC listeners for normal CGI processes

SYNOPSIS

	use Frontier::Responder;
	my $res = Frontier::Responder->new( methods => {
							add => sub{ $_[0] + $_[1] },
							cat => sub{ $_[0] . $_[1] },
						       },
					   );
	print $res->answer;

DESCRIPTION

       Use Frontier::Responder whenever you need to create an XML-RPC listener using a standard CGI interface. To be effective, a script using
       this class will often have to be put a directory from which a web server is authorized to execute CGI programs. An XML-RPC listener using
       this library will be implementing the API of a particular XML-RPC application. Each remote procedure listed in the API of the user defined
       application will correspond to a hash key that is defined in the "new" method of a Frontier::Responder object. This is exactly the way
       Frontier::Daemon works as well.	In order to process the request and get the response, the "answer" method is needed. Its return value is
       XML ready for printing.

       For those new to XML-RPC, here is a brief description of this protocol.	XML-RPC is a way to execute functions on a different machine. Both
       the client's request and listeners response are wrapped up in XML and sent over HTTP. Because the XML-RPC conversation is in XML, the
       implementation languages of the server (here called a listener), and the client can be different. This can be a powerful and simple way to
       have very different platforms work together without acrimony. Implicit in the use of XML-RPC is a contract or API that an XML-RPC listener
       implements and an XML-RPC client calls. The API needs to list not only the various procedures that can be called, but also the XML-RPC
       datatypes expected for input and output. Remember that although Perl is permissive about datatyping, other languages are not.
       Unforuntately, the XML-RPC spec doesn't say how to document the API. It is recomended that the author of a Perl XML-RPC listener should at
       least use POD to explain the API.  This allows for the programmatic generation of a clean web page.

METHODS

       new( OPTIONS )
	   This is the class constructor. As is traditional, it returns a blessed reference to a Frontier::Responder object. It expects arguments
	   to be given like a hash (Perl's named parameter mechanism).	To be effective, populate the "methods" parameter with a hashref that has
	   API procedure names as keys and subroutine references as values. See the SYNOPSIS for a sample usage.

       answer()
	   In order to parse the request and execute the procedure, this method must be called. It returns a XML string that contains the
	   procedure's response. In a typical CGI program, this string will simply be printed to STDOUT.

SEE ALSO

       perl(1), Frontier::RPC2(3)

       <http://www.scripting.com/frontier5/xml/code/rpc.html>

AUTHOR

       Ken MacLeod <ken@bitsko.slc.ut.us> wrote the underlying RPC library.

       Joe Johnston <jjohn@cs.umb.edu> wrote an adaptation of the Frontier::Daemon class to create this CGI XML-RPC listener class.

perl v5.10.1							    2002-08-03						  Frontier::Responder(3pm)

RPC::XML::ParserFactory(3pm)				User Contributed Perl Documentation			      RPC::XML::ParserFactory(3pm)

NAME

       RPC::XML::ParserFactory - A factory class for RPC::XML::Parser objects

SYNOPSIS

	   use RPC::XML::ParserFactory;
	   ...
	   $P = RPC::XML::ParserFactory->new();
	   $P->parse($message);

DESCRIPTION

       The RPC::XML::ParserFactory class encapsulates the process of creating parser objects that adhere to the interface described in
       RPC::XML::Parser.  Under the hood, the parser object created and returned could be from any of a number of implementation classes.

IMPORT-TIME ARGUMENTS
       You can specify a particular underlying parser class to use, if you do not want RPC::XML::ParserFactory to use the default class. This is
       done with the "class" keyword:

	   use RPC::XML::ParserFactory (class => 'XML::Parser');

       The value may be the name for any of the built-in classes, or it may be the name of a class that inherits from RPC::XML::Parser (and can
       thus be "manufactured" by the factory). The value is saved and becomes the default class for any calls to new that do not explicitly name a
       class to use.

       Note that if the specified class is not valid, this is not tested until the first call to new, at which point an invalid class will cause
       an exception (error) to occur. The constructor will return "undef" and the $RPC::XML::ERROR variable will contain the error message.

   Names of Built-In Parsers
       The following names are valid when specified as the value of the "class" argument described above:

       XML::Parser
       xml::parser
       xmlparser
	   All of these specify the parser implementation based on the XML::Parser module. This is the default parser if the user does not specify
	   any alternative.

       XML::LibXML
       xml::libxml
       xmllibxml
	   These specify a parser implementation based on the XML::LibXML module.  This is a new parser and not as well-vetted as the previous
	   one, hence it must be explicitly requested.

SUBROUTINES
/METHODS
       The methods are:

       new([ARGS])
	   Create a new instance of the class. Any extra data passed to the constructor is taken as key/value pairs (not a hash reference) and
	   attached to the object.

	   This method passes all arguments on to the new() method of the chosen implementation class, except for the following:

	   class NAME
	       If the user chooses, they may specify an explicit class to use for parsers when calling new(). If passed, this overrides any value
	       that was given at use-time (processed by import()).

DIAGNOSTICS

       The constructor returns "undef" upon failure, with the error message available in the global variable $RPC::XML::ERROR.

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

       o   RT: CPAN's request tracker

	   http://rt.cpan.org/NoAuth/Bugs.html?Dist=RPC-XML <http://rt.cpan.org/NoAuth/Bugs.html?Dist=RPC-XML>

       o   AnnoCPAN: Annotated CPAN documentation

	   http://annocpan.org/dist/RPC-XML <http://annocpan.org/dist/RPC-XML>

       o   CPAN Ratings

	   http://cpanratings.perl.org/d/RPC-XML <http://cpanratings.perl.org/d/RPC-XML>

       o   Search CPAN

	   http://search.cpan.org/dist/RPC-XML <http://search.cpan.org/dist/RPC-XML>

       o   MetaCPAN

	   https://metacpan.org/release/RPC-XML <https://metacpan.org/release/RPC-XML>

       o   Source code on GitHub

	   http://github.com/rjray/rpc-xml <http://github.com/rjray/rpc-xml>

LICENSE AND COPYRIGHT

       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 <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 <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, RPC::XML::Client, RPC::XML::Server, XML::Parser

AUTHOR

       Randy J. Ray "<rjray@blackperl.com>"

perl v5.14.2							    2011-07-23					      RPC::XML::ParserFactory(3pm)