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 13:18:15 GMT
On 6/6/07, Rupert Smith <rupertlssmith@googlemail.com> 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
>

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