I have a changeset which implements client-side XMLRPC support for
swf8, dhtml, and swf9.
This means that you can do SOLO XMLRPC (conditional on the security
model of the runtime allowing the requests).

I'm thinking of just checking this in, even though it breaks javarpc and soap.

My next task is to make the javarpc responder in the LPS server return
XMLRPC instead of json/swf, and then
java rpc will work again.

After that, the question is what to do about SOAP support.

The quick fix is to modify the DHTML SOAP server side code to return
XMLRPC instead of JSON,
and then SOAP will work as much as it does now, in theory. However, it
might be a good time to
either try to upgrade the apache libraries on the server  to something
more modern for proxied SOAP requests
(gah), or else to try to do a completely client side SOAP
implementation (painful, but would allow SOLO
operation, again subject to security model of the runtime).


-- 
Henry Minsky
Software Architect
[EMAIL PROTECTED]

Reply via email to