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-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
