Hi, Andrew,
good to read you.
Traditionally the decisions made have been quite conservative:
continuing support for Java 1.1, few changes that break the official
specification, using a lot of our own (HTTP, Base64) rather than the
Apache commons code.
To me, the decisions have been too conservative. I understand the desire to use XML-RPC in an Applet. However, only few of us seem to do so. And, besides, there would also be the option to maintain a "Lite" version (possibly evolving from the current sources) and a "Fat" version. (Version 3, possibly)
One of the strengths of Apache XML-RPC is its simplicity, not just in the XML-RPC wire representation, but also in the effort required to compile and use it. With XML-RPC 1.1 this basically meant you had a Java Virtual Machine 1.1 or later, the rest: SAX, HTTP and Object <-> XML transformation was provided by one small JAR file.
I agree. However, currently this simplicity only applies to the possibility to work without late software and API's. See the next point. Besides, I would personally consider it as particularly simple to get rid of self written XML parsers or "Lite" transport in favour of a much smaller code size. (I do accept, however, that this is my personal opinion.)
Furthermore, not all of these patches need to be integrated into
XML-RPC. The current API provides sufficient support for most of them to
be part of the product using XML-RPC rather than part of XML-RPC.
And here's where I disagree: Yes, it is technically possible to do such things with the current API. However, it is definitely far away from being "simple".
XML-RPC is simple to use, as long as you can live with the supported feature set. Everything else is tedious. Why do I have to convert an array or list to a vector? Why is no Map accepted? Why do I need to use a byte array, if I have a serializable object? If you are maintaining a large application with hundreds of possible XML-RPC calls, this sums up. Why do I have to stick to Java 1.1 guidelines, if my client and server use Java 1.4?
Very few patches are submitted with any form of tests or documentation, meet the coding conventions used at Apache, or contain an indication if the standard test suite has been run. This makes it difficult to accept them, as the submitters code already works without changes to XML-RPC, and significant effort is required from committers to develop tests so that other users of the code can have some degree of certainty that the code works.
This is certainly a valid issue. However, I cannot remember a single case, where the response was "your patch is possibly fine, but how about a unit test" (except today, of course).
Many of these patches might be better placed in a 'contrib' package, with less stringent guidelines regarding tests and the like. While they are often of use to their submitters, it is unclear (to me at least) if they are necessary (or usable) for other users of the package.
IMO, the things we are currently talking about are useful for different people. Just take a look at how often the requests are repeated. For example, just like Henri, I am using compression. The only difference is, that I am doing that via an own transport factory. Likewise, you have just quoted for yourself, that collection support is requested frequently.
Regards,
Jochen
