Hi As John suggested these are changes that IMO would ease writng transport plugins:
I think that the apache xmlrpc should be transport independant framework, as such - shouldn't have any http specific classes; http classes should be moved to their own package - shouldn't have any http specific methods; methods like XmlRpc.setKeepAlive() should be moved to the plugin - shouldn't assume that the transport isn't XML already, which implies shouldn't care about encoding - shouldn't assume anyting about low level connections; e.g. while http can use connection per request-response, jabber uses connection per resource on server side and usually 1 connection for whole communication on client side. ** those features allow people to use the framework with other RPCs, even non-XML ones - should allow plugin to define its own representation of message; - should allow plugin to define own SAX handlers and possibly even SAX driver; - client code shouldn't care about transport layer; url is enough to guess which one to use, plugins could register much like drivers in JDBC That's all, at least for now. It may appear that plugin have to redefine everything, but the idea is the plugin provides those components that are different than in traditional XML-RPC and rest takes from HTTP plugin. When client uses this framework with default transport, he gets XML-RPC compilance, on the other hand architecture remains open and people may do whatever they want. Regards
