Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 75AE99C10 for ; Fri, 7 Oct 2011 16:18:48 +0000 (UTC) Received: (qmail 1577 invoked by uid 500); 7 Oct 2011 16:18:48 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 1552 invoked by uid 500); 7 Oct 2011 16:18:48 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 1542 invoked by uid 99); 7 Oct 2011 16:18:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Oct 2011 16:18:48 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gsim@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Oct 2011 16:18:41 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p97GIKnv000517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Oct 2011 12:18:20 -0400 Received: from [10.3.235.248] (vpn-235-248.phx2.redhat.com [10.3.235.248]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p97GIIMi003804 for ; Fri, 7 Oct 2011 12:18:19 -0400 Message-ID: <4E8F2625.6020204@redhat.com> Date: Fri, 07 Oct 2011 17:17:41 +0100 From: Gordon Sim Organization: Red Hat UK Ltd, Registered in England and Wales under Company Registration No. 3798903, Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parsons (USA), Charlie Peters (USA) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b1 Thunderbird/3.0.10 MIME-Version: 1.0 To: users@qpid.apache.org Subject: Re: How to set a binding on a receiver References: <4E8C1629.4060206@list-group.com> <4E8C3164.8010308@redhat.com> <4E8ECADF.3040205@blueyonder.co.uk> <4E8EF3DA.4020600@redhat.com> <4E8EF9DD.7040100@blueyonder.co.uk> In-Reply-To: <4E8EF9DD.7040100@blueyonder.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 On 10/07/2011 02:08 PM, Fraser Adams wrote: > >> I guess it depends on how you interpret 'directly'. What I meant was >> that the API does not support modifying the bindings or other address >> properties for a receiver once it is created. >> > I expect that my interpretation of the term "API" is "looser" than yours > :-) > > I guess that I (in my head at any rate) look on the address options as > part of the messaging API 'cause that's the only way to set many things > that were once explicit method calls in the client API. Your approach use the auto-create feature to create new bindings when creating a new receiver. I view the effect this has on an existing receiver as indirect. The creation of the binding is a side-effect of another operation. That is why I say its a difference of interpretation of 'directly'. Its not because it is done through address options. I don't disagree with the view that the address options are part of the overall API. However address strings are intended to be more malleable than the code that is tied to particular classes and methods. The addresses will generally contain configuration rather than application logic (though I fully accept this is a blurry distinction). --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:users-subscribe@qpid.apache.org