On 05/06/2015 05:22 PM, Rob Godfrey wrote:
So I take the opposite view here I think... Or maybe we just have
different notions of what a shared subscription is.
To me a shared subscription represents an entity that may currently
have 0, 1 or many consumers which "compete" for messages amongst each
other.
I can see that view. I also see the subscribing links as part of a
logical grouping, hence sharing some common group identifier (i.e.
subscription name).
A link represents encapsulates the state of a conversation between two
endpoints in (separate) AMQP containers. The state of two consumers
from the same shared subscription is not in any way shared (or at
least no more so than two consumers on a standard queue).
To me a shared subscription is a logical "node" which the (broker)
container presents to clients. It has state... and links
(subscriptions) to it have state. To me the logical way to represent
the shared subscription is as an address... - one of the proposals
that was kicked around was topic[foo] where foo is the shared
subscription name. As well as what I perceive to be the better
modelling of the notion of a shared subscription, this form also has
the advantage of being easily transcribable, and the consuming client
doesn't actually need to know that the address they are provided with
represents a shared subscription rather than a queue or another type
of node.
That is certainly a very useful property. You could also handle that by
'broker' side configuration.
My main concern with the address is that its already used in various
ways that may not be compatible, to describe various different things.
On top of an extremely complex type system and source/target model, we
now need (an increasingly complex) string syntax.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
