My comments in summary to all emails. 1. Agree with both Robs that we need to abstract configuration and get rid of commons config as a standard dependency. But if people want they can add it under the covers. Just like slf4j allows different logging mechanisms) The current config system allows system properties, file based config, sensible defaults. The absence of each mechanism defaults to the one of the right.
2. I have a very hard time understanding existing JMS applications wanting to use AMQP features (not exposed through JMS) w/o much code changes. That looks like the justification for extending the JMS API (based on comments so far). I agree with Rob Godfrey, that if they want advanced AMQP features it is likely that they will rewrite a reasonable chunk of code to get there application to support the new logic. Compared to that, writing code to use a AMQP API is not much. So what's all this fuss about? 3. JMS is a priority and passing TCK is a priority. My argument is that the Qpid java client should not make JMS the only goal. (I think saying not the main goal was a bit of an overstatement from my part :) , so apologies ) 4. It is sad that folks have failed to see the main point of refactoring is to modularize and achive a layered architecture that is easy to maintain and modify. I didn't do the refactor to create another API. As Robert Godfrey points out, when u rearrange the code in modular way it starts to look like an API between each layers. Regards, Rajith On 6/6/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
> 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
