qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: AMQP 1.0
Date Thu, 19 Mar 2009 14:05:03 GMT
On Thu, Mar 19, 2009 at 9:40 AM, Aidan Skinner <aidan@apache.org> wrote:
> On Thu, Mar 19, 2009 at 1:29 PM, Rajith Attapattu <rajith77@gmail.com> wrote:
>> On Thu, Mar 19, 2009 at 6:36 AM, Aidan Skinner <aidan@apache.org> wrote:
>>> On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim <gsim@redhat.com> wrote:
>
>>> The Java client uses JMS for this to an extent, but we still need a
>>> way of exposing AMQP specific things in ways that are as version
>>> independent as possible (such as the mandatory flag). I've been
>>> kicking around the idea of something like this:
>>>
>>
>> I am of the opinion that you could get 99% of the AMQP stuff while
>> still using pure JMS.
>> I have a few ideas around how to do the immediate flag etc while still
>> using pure JMS.
>> One such idea is to pass in a QPID specific property in the message
>> called "AMQP_IMMEDIATE" and the respective sender method can look for
>> the presense of this flag and put that in the delivery props. When
>
> See, I'm not sure this is really "pure JMS". It may not use any
> non-JMS API, but it does rely on non-JMS semantics.
>
> I can easily see that this improves portability from a "does my code
> compile" PoV. I think it may be quite unhelpful from a "does my code
> still work" PoV however. Having non-JMS features available as non-JMS
> API at least makes their dependence on this more obvious.

Based on my experience with end users I found that people are very
keen on sticking to the JMS API's as much as possible.
Most of them were moving from an existing JMS provider to Qpid.
If they have to use anything vendor specific their strong preference
was to use configuration files, jvm arguments, flags etc...
Using non JMS API's is something they want to avoid as much as possible.

So from an end users pov, when switching a provider I would like to do
as less work as possible and having portable code is a big plus point
IMO.
Even for an existing Qpid user, when switching from an 0-8/0-9 to 0-10
to 1.0 this approach IMO provides a more pain free strategy.


Regards,

Rajith


> - Aidan
>
> --
> Apache Qpid - World Domination through Advanced Message Queueing
> http://qpid.apache.org
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message