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 Fri, 20 Mar 2009 15:26:28 GMT
On Fri, Mar 20, 2009 at 10:58 AM, Aidan Skinner <aidan@apache.org> wrote:
> On Fri, Mar 20, 2009 at 2:50 PM, Rafael Schloming <rafaels@redhat.com> wrote:
>> Aidan Skinner wrote:
>>> On Thu, Mar 19, 2009 at 6:12 PM, Rafael Schloming <rafaels@redhat.com>
>>> wrote:
>> or something like that. But you could do something similar with the
>> destination. Also, I wasn't necessarily thinking that you would cast inside
>> the static method, I think the decorator thing I mentioned earlier is worthy
>> of some exploration, but obviously one of the benefits of having the method
>> is we can change what it does later.
> This sounds like a plan to me. :)
>>> I'm a little confused, are we talking about client config or server
>>> config?
>> I was thinking of client config, specifically what we've traditionally
>> referred to as the "binding URL", although I've never actually understood
>> why it's a URL, and it really doesn't have all that much to do with binding
>> either, particularly in a 1-0 model.
>> I'm actually just thinking that text based config strings for destinations
>> can control a lot of the client behavior we care about, e.g. ack policy,
>> sync policy, prefetch, etc, and this has the benefit of being usable from
>> both a config file and from code, and it is sort of an approved extension
>> point in as much as JMS has them.
> That makes sense. I guess there's really two different aspects of
> portability here.
> There's "I want my new app to be written as portably as possible" in
> which case going for compiler-enforceable extensions probably makes
> sense.
> There's also "I want to port my existing app to Qpid as quickly as
> possible", in which case being able to control any AMQP or Qpid
> specifc things from config without having to change your code is
> probably much more valuable.

It is this second aspect that I was alluding too. This is exactly what
I heard from the customer interaction I had.
I agree with Rafi that we could do a lot more with destination
abstraction than what we are currently doing today.
I also agree with Rob that we should stive to support extentions (both
QPID and AMQP specific) using configuration as much as possible.
I think currrently we do handle a fair bit of extentions using the
above two methods, but certainly a lot more could be improved.

If for some reason we are unable to support a specific feature (I
don't have a good example in mind and the example of immediate flag I
used before is bad, and I believe it could be handled better via the
destination abstraction) then we could look at options like casting or
using a strategy (as rafi pointed out) such as AMQMessage m =
AMQMessage.fromJMSMessage(...) or passing flags (which does looks like
an abuse of the message properties, but could be made to be detected
at compile time by using constants instead of hard coded strings).

But I sure hope that we should be able to cover 99% of the use cases
via the destination abstraction + configuration and the last option in
only in some very rare cases.



> - 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


Rajith Attapattu
Red Hat

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

View raw message