qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: AMQP 1.0
Date Fri, 20 Mar 2009 14:50:04 GMT
Aidan Skinner wrote:
> On Thu, Mar 19, 2009 at 6:12 PM, Rafael Schloming <rafaels@redhat.com> wrote:
>> Robert Godfrey wrote:
>>> That is why I advocate an *interface* rather than casting into
>>> implementation classes.
>> An interface if restricted to only permit features not accessible
>> through vanilla JMS would certainly help, but I still think casting as
>> part of the API unacceptably blurs the boundaries of the API. There is
>> no way to tell what types you're allowed to cast and which interfaces
>> you're allowed to cast it to.
> I've always hated that about Java. I'm pretty firm on the
> bondage-and-discipline side of the strong typing argument though, and
> I realise others mileage may vary.
>> access to the same broker extension. I would probably add an assertion
>> based on the destination, broker vendor/version, etc to verify that the
>> broker and recipient will understand what is being sent.
> I think if we implement non-standard features we should definitely do this.
>>> I understand that you have a pathalogical hatred of casts.  The java
>>> syntax is certainly less than ideal.  However where we are depending
>>> on AMQP specific behaviour it should be called out.
>> It's not casts I dislike. It's casting as part of an API that I dislike
>> since it makes the API unnecessarily blurry. It's also quite trivial to
>> avoid assuming you don't have a pathological hatred of static methods. ;)
> are you talking about something like public static AMQDestination
> toAMQDestination(javax.jms.Destination dest) and that does the cast
> inside AMQDestination?

I was actually thinking about the message case, e.g.:

   AMQMessage m = AMQMessage.fromJMSMessage(...)

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.

>>> Hopefully most AMQP/QPID extensions can be isolated in cofiguration
>>> rather than code...
>> I think the destination abstraction is a reasonably useful way to do
>> this for most things. It gives us one mechanism that is mostly used via
>> configuration but can also be used through code as well with
>> createQueue(...) and friends.
> 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.


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

View raw message