Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of gsim@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <510FDDBB.40809@redhat.com>
Date: Mon, 04 Feb 2013 16:11:39 +0000
From: Gordon Sim <gsim@redhat.com>
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; Linux x86_64;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
References: <510FBD74.4090803@redhat.com>
 <1359989991.1952.5.camel@cratus.office.paradigmaxis.pt>
In-Reply-To: <1359989991.1952.5.camel@cratus.office.paradigmaxis.pt>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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?

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

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


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