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:08:01 GMT
Alan,

We already have a low level AMQP protocol API.
It's exactly a 1-1 map of the protocol level classes.
Similar to Python u can do message.ok , message.transfer ,
connection.secure..etc

Regards,

Rajith.

On 6/6/07, Alan Conway <aconway@redhat.com> wrote:
>
> On Mon, 2007-06-04 at 15:19 +0100, Rupert Smith wrote:
> > On 04/06/07, Tomas Restrepo <tomas.restrepo@devdeo.com> wrote:
> >
> > > I agree this is a valid question, but at least from my point of view,
> > > uniformity of the API isn't such a big deal, for this kind of project
> in
> > > particular. That said, if the API were to be that AMQP-compatible API,
> > > which
> > > is certainly fairly low level, then by that virtue alone the API would
> be
> > > fairly similar across implementations, simply because it would
> resemble
> > > the
> > > AMQP class/method model fairly closely. I believe we'd likely still
> have
> > > some differences for things async operations (which definitely have
> > > different conventions across languages), but that wouldn't be that
> bad.
> > >
> >
> >
> > I can be brought round to this point of view. As you rightly point out
> the
> > API is going to look like the protocol anyway. Also Robert Greigs post
> about
> > developers using the appropriate API for their language and that being
> the
> > one to implement, clarifies what is more important.
> >
> > Rupert
>
> +1 to this: establishing a similar "raw AMQP" API layer in each project
> based on the AMQP XML and building on top of that. I say "similar" not
> "uniform": the XML is the rosetta stone, each language should map the
> XML in the way best suited to that language. However it should be
> possible (although not necessarily promoted to users) to write a client
> on _only_ this API. Higher level APIs (JMS, the current C++ client etc.)
> would be layered on top.
>
> This solves a lot of problems: XML provides common terms that will be
> used in class & method names, this layer can (should) be code generated
> as far as possible so it will automatically extend to cover new protocol
> features, and it will be easier for developers to work across projects -
> they know the concepts, just need to learn the local mapping rules.
>
> This API is low level and tied to protocol changes, so it's not suitable
> for some customers: JMS, NMS and other high level APIs should be based
> on what users in that language are used to.
>
> Python is the best (only?) example so far of a clean "raw AMQP" client.
> I've been wanting to do a consistent "raw AMQP" underpinning for C++ for
> some time now. Is this something to consider for the current Java client
> work?
>
> Cheers,
> Alan.
>
>
>
>

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