On 6/6/07, Robert Greig <[EMAIL PROTECTED]> wrote:
On 06/06/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > 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? I don't think it follows that it is "not much". There is also the additional consideration that if someone is starting out you are creating a choice for them that they may not want to make or feel comfortable making. Maybe on day 1 they are happy with JMS but if by doing that they close the door to using "advanced" AMQP features what should they do? Start with the other "more powerful" API? You are effectively turning the JMS implementation into a second class API. Do not underestimate the cost of change.
[RA] Sorry I don't buy this argument at all. Every project needs to make hard decisions and live with it. You know this more than me. IMHO It's better to have choices. People always feel they could have done it better after a while. This dilemma is every where. Should I use EJB3 or Spring/Hibernate ? should use JPA or not? Should I use log4j or not? These are questions almost everybody runs into. Before evaluating what options to use they need to evaluate their long term goals of the project. If they think they might use advanced AMQP features, yes why not use the "Almighty" API :) This in anyway doesn't devalue JMS or make it second class. If they only need JMS then they will use JMS. If they want more AMQP stuff then they will use that. It's all about using the right tool for the right job. If u want to cut angles u use the miter saw and not the table saw (even though some allows u to tilt the blade). Does that mean that the table saw is second class to the miter saw ??
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. We need to have a discussion about our API strategy. Without getting agreement on that now this discussion will keep coming up.
[RA] The API strategy has nothing to do with the main goal of re-factoring. There is enough consensus that we need more modularity and clear separation of layers. I think we had this discussion about API strategy several times over the last two years. And this is likely to continue for a while.
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. I am sure there are many products that internally have layers that "look like APIs" but the question is whether you promote those APIs for people to build applications against.
[RA] Whether we advertise or not people will use what they want. A good example is what Hiram did to get AMQP support for ActiveMQ. However I would personally opt to promote the low level API at the least. Robert Godfrey likes to see Qpid java client as well (I am neutral here). Let people use what they want. RG
