> > 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)
I think that version 3 is the place for most of this. It is certainly not going to be acceptable for 1.2. If someone can provide a either a convincing argument that 2.0 is not being used in applets, or a patch that allowed Collections support without breaking support for Java 1.1 then that would be something acceptable for 2.0. I will look into how we can support Collections without breaking Java 1.1 support tomorrow. I'm fairly sure that it is possible, and this would (hopefully) be a solution that satisfies both camps. > > 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. The code on HEAD works with recent XML parsers, commons-httpclient 2.0 (I expect with 3.0 too), and I would expect it to work with Java 1.5. The one thing that we don't support is Collections, previous discussion on this list should make it clear that this has been a deliberate decision. No-one has yet submitted a patch that addresses this. > > 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". I agree that things could be made easier, but I think that as much as possible they should be done without breaking the current API. Patches that make an effort to preserve the current API and behaviour are more likely to be accepted. > > 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). I think and other committers on this and other lists tend to look at patches from the perspective of the effort taken by the contributor and the effort required by the committer. If the contributor has clearly spent time to make the patch easy to integrate, it is more likely to be integrated. Squeaky wheels do tend to get grease (at least where I'm involved). If you squeak the right way (eg. via the bug tracker) and make your patch easy to integrate (eg. with unit tests), it is much more likely to be integrated. Both Daniel and I have also provided reasons for rejecting patches in the past where contributors have asked for them. Andrew.
