The current implementation of XML-RPC is dependent on the LPS server to do proxying of XML-RPC requests, and re-encoding of the results coming back as either JSON (for DHTML runtime) or swf7 byte coded binary files for swf8.
To simplify support for swf9, and to give the client the capability to do SOLO XML-RPC requests, it would be better to receive the XML-RPC responses on the client and decode them there. In SOLO mode this will mean directly contacting the XML-RPC server. For proxie requests (presumably done to get around security limitations on accessing some 3rd party services), the LPS server will return the XML response to the client verbatim; it will no longer be in the business of implementing XML-RPC protocol as a proxy, and re-encoding the responses as JSON or swf byte code. subtasks: + implement proper SOLO raw post of well formed XML for swf8 (this should be quick, and is a feature that is being asked for by other users) + implement object deserializer in javascript modify RPC library to use rawpostbody message. + convert the existing RPC library to use the deserialized XML-RPC -- this approach would also probably be used for JavaRPC-- we can convert the existing LPS server responder to send back XML-RPC format instead of JSON or swf byte code. I'm not sure if I should implement XML-RPC object deserialization at a low level using native XML objects (the deserializer code would be slightly different for the three platforms because of the slightly different platform XML APIs),or convert the native XML to an LzDataElement tree and then deserialize that (it's an extra computational step, but would make the deserializer code unified). I'll probably start out converting the XML response to an LzDataElement, in order to get something running as quickly as possible on all runtimes, and if there are performance issues, we can revisit that and make a "native API" deserializer for each runtime. -- Henry Minsky Software Architect [EMAIL PROTECTED]
