qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: on how to use the qpid java client
Date Wed, 06 Jun 2007 14:04:22 GMT
On 6/6/07, Robert Greig <robert.j.greig@gmail.com> wrote:
> On 06/06/07, Rajith Attapattu <rajith77@gmail.com> 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
> > 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message