Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <1360061189.1810.8.camel@cratus.office.paradigmaxis.pt>
Subject: Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
From: Bruno Matos <bruno.matos@paradigmaxis.pt>
Reply-To: bruno.matos@paradigmaxis.pt
To: users@qpid.apache.org
Date: Tue, 05 Feb 2013 10:46:29 +0000
In-Reply-To: <510FDDBB.40809@redhat.com>
References: <510FBD74.4090803@redhat.com>
	 <1359989991.1952.5.camel@cratus.office.paradigmaxis.pt>
	 <510FDDBB.40809@redhat.com>
Organization: ParadigmaXis, S.A.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Hi Gordon,

On Seg, 2013-02-04 at 16:11 +0000, Gordon Sim wrote:
> On 02/04/2013 02:59 PM, Bruno Matos wrote:
> > Hi Gordon,
> >
> > * support for the assert option
> >
> > This support includes disable all assertions, including the existence of
> > the endpoint, as we discussed some time ago?
> 
> Good question! Though in 1.0 the situation is somewhat different from 
> 0-10[1], calls to createSender()/createReceiver() do still block until a 
> response has been received from the server allowing validation of the 
> target or source.
> 
> That is certainly something that can be relaxed. However I'm not 
> convinced that the assert option is the right mechanism. I think the 
> most direct and clear way of offering users the choice there would be to 
> overload the methods with variants that took a sync flag (much like with 
> send() and acknowledge()). What do you think?

Would be something like 'session.createSender(address, dontVerify)' ?

> 
> I'd be happy to add that to my list. Do we have a JIRA for it already do 
> you remember?

I don't remember, but I took a look at the mail thread and did a search
in JIRA and I didn't find anything.

> 
> --Gordon
> 
> [1] In 0-10 there is a synchronous queue- or exchange- declare issued 
> when creating a sender or receiver. Since 0-10 only allows messages to 
> be sent to an exchange, messages actually intended for queues that don't 
> exist are simply dropped. The declare was mainly motivated by the desire 
> to make that situation more explicit. There is of course also a 
> 'resolution' of the node, i.e. a query (an exchange-bound command to be 
> precise) to determine whether the node is a queue or an exchange. This 
> stage is also synchronous but can be disabled by explicitly identifying 
> the type in the address.
> 
> In 1.0 all that is needed is an attach notification by the client which 
> is then echoed by the broker. Messages can only be sent on an attached 
> link and the clients needn't actually know anything about the node type 
> (unless of course they want to verify certain capabilities).
> 

Thank you,
Regards.

-- 
Bruno Matos


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org