On Ter, 2013-02-05 at 11:54 +0000, Gordon Sim wrote: > On 02/05/2013 10:46 AM, Bruno Matos wrote: > > 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 would call the second parameter 'sync' I think, it would be a boolean > which when true would give the current synchronous behaviour, i.e. the > call would block until the server responded (and would then throw an > error if the server indicated there was no such node or its properties > were not as requested, or permission was denied etc). If the value was > false then the call would return as soon as the request had been issued > and return from the method would not guarantee that the sender/receiver > was actually linked to a valid node.
It may not be obvious that an async call will ignore the validations. But for me it's just fine. Thank you, Regards. -- Bruno Matos --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
