> > Yes but this isn't XML-RPC and XML-RPC is what the Apache code is > > supposed to implement. > > I thought the whole idea about abstracting the transport layer was > breaking the spec.
The idea of abstracting the transport layer was to make it easier to work with custom or different HTTP implementations. There are almost as many HTTP implementations as there are programmers, and some servers are more fussy about what they accept. It also allows simpler implementation of HTTPS, and enhancements outside of the spec (eg. use of HTTP headers) which are implementation dependent. The original code already had two HTTP implementations, 'full' and 'lite', and people wanted to extend this to support HTTPS, and HTTP using an external client or server implementation (eg. an internal HTTP library, or embedding the server within a servlet). > You implement XML-RPC only in the default plugin, the rest is just a > framework, a code that does common things and if you support different > transports, putting the prolog into message isn't common, because Well, the goal of the package when it was first created was to create a Java implementation of the XML-RPC specification. This is (as far as I know) still the main goal. We'd like to make things more accessible and customizable to developers, but not to the extent that we encourage people to do things that break interoperability. The reason that the code is moving more in the direction of being a framework is to increase options for developers who want to embed XML-RPC in their application. The old server code was quite monolithic, it is now possible to embed the Apache XML-RPC server in your own client and server code. However, the library itself promotes interoperation. Andrew.
