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.
[RA] I (and Kim) tried to re-factor first w/o much success. Maybe we haven't tried enough or took the wrong approach Writing from scratch was the second option and not the first. If somebody can re-factor the existing code to achieve the same level of separation and modularity then it is great. Apache decision making is based on merit and if you or Robert Greig can re-factor the existing code satisfactorily then I think the community will opt to keep the existing client. I waited for almost a year before I made this attempt, but I am happy to concede if the above happens. 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.
[RA] These decisions were made collectively as a group. It may or may not have been the right decision. But the protocol was in such a state of flux, most plans got derailed. 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.
[RA] The JMS layer introduces at least one context switch as apposed to the low level AMQP API. When u implement message listener etc, u need to build that threading model on top of the AMQP API. The difference in performance as u said is negligible compared to encoding/decoding. But for projects who wants to use AMQP under the covers will prefer one less context switch if that is possible. So instead of using JMS, they will use the AMQP low level client. (Apart from the fact that the AMQP client provides full support to all AMQP features) 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).
[RA] People will choose what they want to use depending on their situations. 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...
[RA] We can always choose to be negative and bitch about maven at every opportunity we get. But don't forget most people who hate maven LOVES ant. Now is Ant an open source project or not ? And mind you they are still making improvements and there is still innovation happening in ant. Rupert
