On 09/21/2012 10:51 PM, Rajith Attapattu wrote:
Gordon I'm not comparing the API's here. I'm comparing the *implementations of those API's*. My assumption is that the Qpid API implementation will likely use a logging façade like slf4j and perhaps some other dependencies, while the Messenger implementation will be dependency free and more compact.
I am challenging that assumption (and the inference you drew from it regarding the attractiveness of particular - as yet unimplemented - APIs in particular environments).
Why would the needs of users of these APIs with regard to logging be different? If they aren't why would we pursue two different approaches to meeting those needs and why would we align a particular approach with a particular API?
[...]
I agree with you that there is a lot of overlap btw the JMS and Qpid API in terms of functionality and behaviour. Infact the Qpid API seems like a superset of the JMS API I also agree from a design point of view it seems cleaner. But as I said I'm not discounting either approach. It's always good to investigate all approaches and look into all kinds of factor not just technical.
Are there non-technical advantages that you see with option #2?
Until recently I have considered only option #1 (JMS --> Qpid API --> Proton, but I have heard people looking at option #2 as well. It's always good to consider all options
Certainly. I am not suggesting otherwise, merely trying to establish the case for the second option you presented.
I can understand a reluctance to have another public API.; but from what you are saying that isn't really a factor in you're mind with option #2?
(While you are laying out *all* the options, it might be useful to include the current approach for JMS over AMQP 1.0, as included in the 0.18 release. What are the particular issues that we would want to address by picking another approach?).
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
