On Mon, 2006-09-18 at 16:39 +0100, Gordon Sim wrote: > The point of the AMQP API is not that it is more efficient or less > repulsive but that it more directly reflects the protocol. JMS has its > model, which will be what the majority will be familiar with and use. > AMQP has its own model so why not have an API that reflects that model > more naturally?
I don't see "reflecting the protocol" as a goal for an API. I see "making it easy for users to what they want" as the main goal. There's no doubt that Qpid for java will include JMS + Qpid specific stuff because qpid has features that JMS doesn't. The principal point of debate is: will the qpid specific stuff provide alternative ways to do what JMS does already, or not? I'm not saying it shouldn't. I'm asking: Why should it? What would be different and better (for the user) about a native Qpid equivalent of JMS? I have some experience with the cost of testing, maintaining and supporting duplicate APIs, I'm trying to understand what is the benefit that outweighs it. Cheers, Alan.
