I picked up a comment on my post about XchemeRPC:
| please post xschemerpc 2.0! |
The 80/20 rule always gets you: in my case, it was getting conformance/interop with other XML-RPC implementations. At this moment, things work great with the Apache XML-RPC implementation (Scheme client to Java server, and visa-versa), and between XchemeRPC clients and servers, which is a good start. I haven’t tested other major implementations (Perl, PHP) which is a problem; hopefully (big assumption!) there’s a bit of transitivity working for me: if I interop with Apache XML-RPC, then I might interop with clients and servers that work with it.
Why hadn’t I released it sooner? For the first time since I wrote the first version, I’ve had an app where XML-RPC was an appropriate tool (I needed to interact with a Movable Type installation), and I really needed some additional server-side support. Furthermore, I absolutely needed my XML-RPC code to run as an Apache CGI. V2.0 does this, and it works (meaning: it solved my problem in a simple way).
I’ll package it up and post it this weekend. It has docs, and is as ready to go as it needs to be for the moment. I don’t have full unit test coverage, which is unfortunate, but that will have to be excusable for the moment.
UPDATE, next morning
Well, that’s silly. I’m currently capable of interacting with Movable Type via it’s XML-RPC interface using my library. Therefore, this must necessarily mean that XchemeRPC works with SOAP::Lite. Duh.