On 07/06/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
On 6/7/07, Robert Godfrey <[EMAIL PROTECTED]> 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.
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.
-- Rob
> On 07/06/07, Jonathan Robie <[EMAIL PROTECTED]> 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
> >
>
