Hi, all. I'm in the process of evaluating XML-RPC for a new project. I'm
wondering if anybody else has looked at XML-RPC to see how it might integrate
with Turbine, and more importantly whether it should.
An example scenario in Turbine:
Components:
- XmlRpcServer: singleton that manages handler mappings and execution
- XmlRpcScreen: a Screen that uses XmlRpcServer to execute the XML
method-call it receives via the HTTP request
Process (after authentication):
1. Turbine receives a request for XmlRpcScreen.
2. XmlRpcScreen gets a reference to XmlRpcServer.
3. Upon instantiation, XmlRpcServer retrieves the handler mappings from
TurbineResources and adds them to its internal hashtable.
4. XmlRpcScreen calls XmlRpcServer.execute(data.req.getInputStream()). All
logic for parsing the XML method-call and executing the handler are
encapsulated within XmlRpcServer. (For more details, see the class of
the same name in the "Library for Java". See "References" below.)
5. XmlRpcServer.execute() returns a string (i.e., the response XML doc),
which XmlRpcScreen passes back to the client after setting a few
headers.
Basically, the screen class would work like jon's new ImageServer screen, and
the server class would be an amalgamation of the existing java library. From
an implementation stand-point it shouldn't be too difficult. However, I'm
interested in opinions on the appropriateness of such an endeavor. Does it
make sense to put this in Turbine? Are there potential problems I'm not seeing?
Thanks in advance for any and all opinions.
--
Christopher Elkins
---
References:
XML-RPC Home Page <http://www.xmlrpc.com/>
XML-RPC Specification <http://www.xmlrpc.com/spec/>
XML-RPC Library for Java <http://helma.at/hannes/xmlrpc/>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
