Need new transport library
Apache XMLRPC isn't cutting it. I really need to be able to set cookies and use them while doing XMLRPC, and Apache's just isn't built for that. (There's a request for cookie support in the whole bug thing and it's marked as major, but I don't know if I want to wait that long.) I'm pretty sure a simpler approach would be just fine here. Furthermore, LJ's XMLRPC interface isn't as complete as the flat interface. XMLRPC also doesn't serve for the comments exporting interface. I think LJ's XMLRPC able to set console commands, which the flat can't do, but that's it. And SB's XMLRPC interface is just sad. And pathetic. So an additional class will need to be able to do the regular POST/GET stuff anyway. And it seems stupid to keep one library that's using one transport and then have to set up additional transports in order to do any flat things, which is inevitable.
This means:
* Will need to implement an XMLRPC interface class that can create XMLRPC requests and also receive them. Apache's strategies are a good starting line for that kind of behavior.
* Will need to pick an xml writer/parser and use it for the XMLRPC and other stuff like the comment exports.
* Will need to implement a class that takes care of all of the back and forth of sending pages to the server and receiving them back. It should be able to set cookies for the authentication, because doing all these challenge/responses over and over sucks ass.
This means:
* Will need to implement an XMLRPC interface class that can create XMLRPC requests and also receive them. Apache's strategies are a good starting line for that kind of behavior.
* Will need to pick an xml writer/parser and use it for the XMLRPC and other stuff like the comment exports.
* Will need to implement a class that takes care of all of the back and forth of sending pages to the server and receiving them back. It should be able to set cookies for the authentication, because doing all these challenge/responses over and over sucks ass.