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 Thu, 07 Jun 2007 16:22:20 GMT
On 6/7/07, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
>
> On 07/06/07, Rajith Attapattu <rajith77@gmail.com> wrote:
> > On 6/7/07, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
> > >
> > > Just to add a few thoughts...
> > >
> > > In the AMQP working group we have been talking about some sort of
> > > standardisation of an AMQP API.  If such a standardisation takes place
> > > I would expect each Qpid client library to implement to that standard.
> > > Before such a standardisation we obviously running a risk by defining
> > > our own API that it is not substancially the same as that agreed by
> > > the AMQP working group - then we would be having to support three
> > > separate APIs :-(
> >
> >
> > [RA] Robert, I always thought the protocol classes defined in AMQP is
> the
> > API.
>
> There is API and there is API... With 0-10 (and even 0-8/0-9) certain
> classes are not meant for application use, but for use within the
> library (the Connection in 0-8 for instance).  There is more of this
> in 0-10, operating at different layers.
>
> The we have things like pre-fetch windows, handling of large messages
> (deal with them as single entities or stream the message in/out)...
> These things provoke design choices.
>
> The AMQP class and method "API" is far too raw to actually be
> presented as is to an application programmer IMHO.


[RA] Well depends on what people are looking for.

> I am not sure how we can define anything different. Please correct me if I
> > have missed something.
> > The AMQP API, I have is essentially a 1-1 map of the protocol classes
> > defined. (the same route Rafi has taken in python).
> > I didn't invent anything.
> >
>
> The python client makes some decisions about how it implements message
> listeners, threading models, etc... so will your code.  These are
> (again) design decisions.  They do not follow directly from the
> protocol spec.
>
> > My view remains that we should build an internal API based on AMQP in
> > > terms of which we write our JMS implementation.  I would not be
> > > encouraging our users to use that "AMQP" API until such time as AMQP
> > > has sufficiently stabilized and established API guidlines.
> >
> >
> > [RA] There are other apache projects and we have customers who are
> willing
> > to use the API and are aware of the risks.
> > Some of these folks are not too  crazy about JMS. If they are willing to
> > use it , then let them do it.
>
> > After all if we are only JMS, what is the differentiating factor btw us
> and
> > ActiveMQ ? (ActiveMQ will also support AMQP at one point).
>
> If ActiveMQ support JMS over AMQP, that's great.
>
> Also I specifically expressed the desire to support an AMQP
> *standards* API.  What I am very wary about is offering up a *QPID*
> AMQP API to the general public as an alternative to JMS.


[RA] I am also not keen to offer a *QPID* AMQP API.
Currently my protocol level AMQP API is what I think is a substitute for a
standard AMQP API.
When the protocol group gets to define this, I will make the nessacery
changes (hopefully not much) to support that.
People who currently want to use the low level AMQP API will do so with the
explicit understanding that it will change btw versions and obviously when
we define this *standard* API.

On a seperate note, you mentioned during a call with Gordon and me about
your desire to have a Qpid java client in addition to the JMS client.
Are you still keen on that?

I'd rather like to have the AMQP API and the JMS client layered on top. We
can have several internal APIs for layering etc, but I guess we should only
promote the two I mentioned. what do u think?

-- Rob
>
> > > On 07/06/07, Jonathan Robie <jonathan.robie@redhat.com> wrote:
> > > > Martin Ritchie wrote:
> > > > > I think that not allowing AMQP functionality via an extended JMS
> API
> > > > > is a mistake. Going down this route would, IMHO, detriment AMQP.
> > > > I also think that not allowing AMQP functionality via a pure AMQ API
> is
> > > > a mistake.
> > > >
> > > > Isn't the obvious solution to have two APIs?
> > > >
> > > > And if someone has learned the AMQP model, and wants to work with
> AMQP,
> > > > why should they have to learn JMS first?
> > > >
> > > > >> > [RA]  I'd rather like to say that JMS support is a nice
value
> > > > >> addition than
> > > > >> > the main goal of Qpid java.
> > > > >>
> > > > >> I find that a staggering statement. To help me understand can
you
> > > > >> please explain what you think the main goal of Qpid Java is?
> > > > > I have to agree... the Qpid Java clients first goal should be JMS
> > > > > support otherwise it is just another incompatible messaging
> product
> > > > > requiring large scale re-engineering of existing code.
> > > >
> > > > This reminds me of the old arguments in the XML community about
> whether
> > > > our standards should be designed to support documents or data. If
> XML
> > > > didn't have really good support for both, it would not have
> succeeded
> > > > the way it has.
> > > >
> > > > Of course support for JMS is crucially important. But if that's all
> we
> > > > do, I think we've missed a rare opportunity to dramatically simplify
> > > > interoperable computing across languages and platforms.
> > > >
> > > > If all we care about is JMS, let's stop spending time thinking about
> > > > anything else. But of course, the write answer is to create a really
> > > > good hub that can be used for JMS and other existing and future
> systems,
> > > > but also can be used quite nicely all by itself. In standard
> computer
> > > > science terms, let's keep these systems orthogonal, but make sure
> they
> > > > work very well together.
> > > >
> > > > Jonathan
> > > >
> > >
> >
>

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