[rabbitmq-discuss] request for help!

Alexis Richardson alexis.richardson at gmail.com
Thu May 6 17:12:51 BST 2010


On Thu, May 6, 2010 at 5:07 PM, Gordon Sim <gsim at redhat.com> wrote:
>
> I would expect an implementation to define policy around where links
> with these two types of distribution mode can be used. E.g. a pub-sub
> topic might only allow non-destructive links were valid, a plain queue
> might only allow destructive links and a browsable queue might allow
> both (with what I think are then obvious if non-deterministic
> implications for concurrent links with different modes).

Is there any use case where 'destructive' or 'non destructive'
behaviour should be a property of the LINK rather than the NODE?

alexis






> (I myself prefer the terms acquiring/non-acquiring to
> destructive/non-destructive, but the names used aren't critical).
>
>> I understand that there's a desire to accommodate e.g., JMS-like
>> semantics (which I can see may have been a motivating force for
>> "distribution mode").  But I think the core spec can leave room for
>> those, without taking a position otherwise.
>>
>> What the spec does at the minute is to have a model that tries to
>> encompass all possibilities, where it ought to be silent.
>
> I think it is important to be able to indicate which behaviour you
> require/expect (i.e. whether you want to exclusively 'acquire' the
> message or not). I think the details of what the node you are linking to
> allows with regard to distribution mode should indeed be left
> unspecified at this level (as it is).
>
> I view book IV as defining the minimal requirements beyond the basic
> transport (i.e. book III), allowing semantic interoperability for the
> common, basic messaging patterns without placing unnecessary burdens or
> constraints on implementations.
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>



More information about the rabbitmq-discuss mailing list