On Fri, May 9, 2008 at 8:55 AM, Rafael Schloming <[EMAIL PROTECTED]> wrote:
> I would also caution that the low level API is most certainly less stable > than JMS for two reasons: 1) AMQP itself has not reached 1.0 and is subject > to certain changes until it does, and 2) our low level implementation is > itself also subject to change. If you're willing to track these changes > closely and likely become more involved in the qpid community then this may > not be a problem, but if you just want to write your code and forget about > it then JMS is probably the safer bet. I second that. If you write against the current low level API then you have to factor in the pain to do code changes if you want to move to a new AMQP version. This is true for python, c++ as well. Things will be more stable when we reach the 1.0 version. > > Robert Greig wrote: > >> 2008/5/9 Rajith Attapattu <[EMAIL PROTECTED]>: >> >> Some of the reasons for using the AMQP API directly would be, >>> =============================================== >>> You want to dynamically create/delete exchanges/queues/bindings as part >>> of >>> the application logic. >>> The JMS API works well if you pre create your exchange/queues/bindings >>> using >>> the JNDI properties file. >>> >> >> This is true just now but it does not imply that you need an "AMQP >> API" to do that since it does not conflict with a JMS API. You could >> easily add this capability to our "extended JMS API" and that is >> definitely what I would like to see if users want it. >> >> If your application needs to query for different exchanges, bindings, >>> queuesis etc as part of your application logic then you would need to use >>> the AMQP >>> API >>> >> >> Again, since this doesn't conflict with JMS it could be added to our API. >> > > I agree, I even think a lot of this could be done without requiring casting > to our own APIs, e.g. we could provide special topics/queues that permit > apps to access/manipulate broker wiring using ordinary JMS messages. > +1. This is my prefered way to do it as opposed to an extended JMS API where you have to cast down to specific classes. > > If you want to have very fine grain flow controlling. The JMS impl deals >>> with only message units and use window mode (however we should make the >>> byte >>> units configurable). If your application needs to switch between the >>> different flow control modes and/or change byte/message credits >>> dynamically >>> as part of application logic then using the AMQP API makes sense. >>> >> >> I think it would be interesting to see if we could add this into the >> JMS API. I need to understand the flow control in 0-10 a bit more >> before I could really comment however. >> > > This only makes sense to use for messages that won't easily fit into > memory, however I believe you could expose the functionality through > BytesMessage. +1 for exposing as much functionality as possible through pure JMS. > > > --Rafael > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
