On 09/20/2012 01:52 PM, Rajith Attapattu wrote:
Steve, there has been several inquiries about using AMQP in mobile environments. I would assume Messenger API (defined in proton) is going to be more attractive in those env's due to it's low footprint. JMS may not be as attractive an option as the above (or even the Messaging API defined in Qpid) due to dependencies and even restrictions in some cases. For example the javax namespace is not allowed in Android.
Certainly the javax related baggage that comes with JMS is a drawback in certain environments. The current JMS interface also has some functional deficiencies (e.g. no confirmation of asynchronous sends).
However I am curious as to what dependencies and/or restrictions the Qpid messaging API imposes? Also what precisely you mean by footprint here and why the Messenger API would necessarily have a lower footprint?
In your original point on the two routes to 1.0 support in JMS (not forgetting of course that 0.18 already has full JMS support over AMQP 1.0, verified both against the Qpid java broker and SwiftMQ), you have 'Proton' as the base in both cases but don't say specifically which part of it you mean - I assume you mean the engine?
If so, the one observation I would offer is that the bulk of the work needed for something like the API currently available in c++ in the qpid::messaging namespace would be required there anyway. It is after all very similar in style to JMS without the issues mentioned above. My instinct is that having an explicit interface somewhere between the JMS and Proton Engine APIs will actually contribute to a cleaner simpler implementation.
The question then seems to me whether there is value in exposing that interface, and offering user the option of avoiding the limitations imposed by JMS without loss of functionality and keeping a similar style. I myself believe there is.
The Messenger API, at least as I understood it, was to be for the simplest use cases. Would a more fully functional API without the baggage of JMS but offering similar (indeed a little expanded) level of functionality not be valuable? I myself believe it would.
You say you believe we should seriously consider option #1. What do you see as the advantage of that over #2? Is it simply avoiding the maintenance of another public API?
I agree very much with Rob's point on the need for greater clarity on the functionality offered by different APIs.
--Gordon --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
