You can argue for refactoring of the client codebase (as I would) without saying that we need to write a new API.
This is what I am for; refactoring as opposed to rewriting from scratch. Refactoring in order to introduce a hole in which to place the new layer. Starting from scratch seems like the easy option, because it avoids the graft of documenting the existing solution, and writing regression tests for bug fixes against it. I'm not coming from the point of view of someone who is defending his own work against being abandoned, after all the existing client code is not my work, I've only just started looking at it ;) I remain open to liking the design of the new client better, so I'm not making a judgement on one lot of code being better than the other. I'm really just thinking about what is best in terms of process, and capturing and carrying quality forward (in terms of bug fixes, performance tweaks, features users have asked for) and maturing the code. Ideally a release branch would undergo a contained period of bug-fixing, with fixes being merged onto trunk, strengthening the code on trunk. I see a conflict arising from this as much as an opportunity to resolve differences in opinion, as an irritating difference in lines of code to be resolved. But at the end of a release branch, trunk should be carrying a lot of fixes forward and being better for it. Otherwise, why am I bothering to merge changes to trunk? The M2 branch was cut prematurely, under the argument that trunk was needed for 0.9, but we knew at the time that 0.9 was going to be skipped over straight to 0.10. It would have been better to postpone it till things were nearing a state of completion on trunk, as this would have focussed our energies on completing something before forging ahead on new stuff. If the layering is so deep as to make the JMS interface notably less performant than the AMQ layer, then the design needs some work. I'm still working under the assumption that the CPU is going to spend most of its time encoding/decoding the bytes as this is not Java's forte, so the amount of layering may have a negligable impact, and my questions around performance versus layering just a red herring. The only way to know for sure is to take some measurements. We need to: make sure we don't let our customers code to non-JMS API features (sensible and already true in almost all cases), make sure the bug fixes that are in M2 have tests (true in many cases, I have a feeling we'll be writing some more regression tests soon). Also, I want to be following Robert Godfreys lead on the architecture, once he is free from the 0.10 spec, and once we've nailed M2.
Continuous innovation is the way forward. That's what people expect from open source projects as opposed to proprietary projects.
Yup, that's why people have come to expect such wonders as Maven 2 from the OS world. Now, if only they'd finished Maven 1 first, I thought it was ok... Rupert
