{ "content": [ { "type": "text", "text": "# Frontier::Responder (perldoc)\n\n## NAME\n\nFrontier::Responder - Create XML-RPC listeners for normal CGI processes\n\n## SYNOPSIS\n\nuse Frontier::Responder;\nmy $res = Frontier::Responder->new( methods => {\nadd => sub{ $[0] + $[1] },\ncat => sub{ $[0] . $[1] },\n},\n);\nprint $res->answer;\n\n## DESCRIPTION\n\nUse *Frontier::Responder* whenever you need to create an XML-RPC listener using a standard CGI\ninterface. To be effective, a script using this class will often have to be put a directory from\nwhich a web server is authorized to execute CGI programs. An XML-RPC listener using this library\nwill be implementing the API of a particular XML-RPC application. Each remote procedure listed\nin the API of the user defined application will correspond to a hash key that is defined in the\n\"new\" method of a *Frontier::Responder* object. This is exactly the way *Frontier::Daemon* works\nas well. In order to process the request and get the response, the \"answer\" method is needed.\nIts return value is XML ready for printing.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **METHODS** (2 subsections)\n- **SEE ALSO** (1 subsections)\n- **AUTHOR**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "Frontier::Responder", "section": "", "mode": "perldoc", "summary": "Frontier::Responder - Create XML-RPC listeners for normal CGI processes", "synopsis": "use Frontier::Responder;\nmy $res = Frontier::Responder->new( methods => {\nadd => sub{ $[0] + $[1] },\ncat => sub{ $[0] . $[1] },\n},\n);\nprint $res->answer;", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 8, "subsections": [] }, { "name": "DESCRIPTION", "lines": 22, "subsections": [] }, { "name": "METHODS", "lines": 1, "subsections": [ { "name": "new", "lines": 6 }, { "name": "answer", "lines": 4 } ] }, { "name": "SEE ALSO", "lines": 1, "subsections": [ { "name": "perl", "lines": 2 } ] }, { "name": "AUTHOR", "lines": 5, "subsections": [] } ], "sections": { "NAME": { "content": "Frontier::Responder - Create XML-RPC listeners for normal CGI processes\n", "subsections": [] }, "SYNOPSIS": { "content": "use Frontier::Responder;\nmy $res = Frontier::Responder->new( methods => {\nadd => sub{ $[0] + $[1] },\ncat => sub{ $[0] . $[1] },\n},\n);\nprint $res->answer;\n", "subsections": [] }, "DESCRIPTION": { "content": "Use *Frontier::Responder* whenever you need to create an XML-RPC listener using a standard CGI\ninterface. To be effective, a script using this class will often have to be put a directory from\nwhich a web server is authorized to execute CGI programs. An XML-RPC listener using this library\nwill be implementing the API of a particular XML-RPC application. Each remote procedure listed\nin the API of the user defined application will correspond to a hash key that is defined in the\n\"new\" method of a *Frontier::Responder* object. This is exactly the way *Frontier::Daemon* works\nas well. In order to process the request and get the response, the \"answer\" method is needed.\nIts return value is XML ready for printing.\n\nFor those new to XML-RPC, here is a brief description of this protocol. XML-RPC is a way to\nexecute functions on a different machine. Both the client's request and listeners response are\nwrapped up in XML and sent over HTTP. Because the XML-RPC conversation is in XML, the\nimplementation languages of the server (here called a *listener*), and the client can be\ndifferent. This can be a powerful and simple way to have very different platforms work together\nwithout acrimony. Implicit in the use of XML-RPC is a contract or API that an XML-RPC listener\nimplements and an XML-RPC client calls. The API needs to list not only the various procedures\nthat can be called, but also the XML-RPC datatypes expected for input and output. Remember that\nalthough Perl is permissive about datatyping, other languages are not. Unforuntately, the\nXML-RPC spec doesn't say how to document the API. It is recommended that the author of a Perl\nXML-RPC listener should at least use POD to explain the API. This allows for the programmatic\ngeneration of a clean web page.\n", "subsections": [] }, "METHODS": { "content": "", "subsections": [ { "name": "new", "content": "This is the class constructor. As is traditional, it returns a blessed reference to a\n*Frontier::Responder* object. It expects arguments to be given like a hash (Perl's named\nparameter mechanism). To be effective, populate the \"methods\" parameter with a hashref that\nhas API procedure names as keys and subroutine references as values. See the SYNOPSIS for a\nsample usage.\n" }, { "name": "answer", "content": "In order to parse the request and execute the procedure, this method must be called. It\nreturns a XML string that contains the procedure's response. In a typical CGI program, this\nstring will simply be printed to STDOUT.\n" } ] }, "SEE ALSO": { "content": "", "subsections": [ { "name": "perl", "content": "\n" } ] }, "AUTHOR": { "content": "Ken MacLeod wrote the underlying RPC library.\n\nJoe Johnston wrote an adaptation of the Frontier::Daemon class to create this\nCGI XML-RPC listener class.\n", "subsections": [] } } } }