On 6 May 2015 at 18:02, Gordon Sim <[email protected]> wrote: > On 05/06/2015 04:34 PM, Robbie Gemmell wrote: >> >> We progressed an idea around an extended use the 'shared' capability. >> The main issue with using just the capability and link name is that >> links have to be unique (in a given direction) based on the >> conainer-id-1 + link-name + container-id-2 triplet, so for a >> particular 'broker container' that would limit you to having a single >> subscriber per set of connections using the same container id, which >> partly defeats the intent. As a result, we also ended up looking at >> ways to encode the subscription name into the address. > > > Or use a link property. That was my original intention, but due to > PROTON-335 I couldn't do so. I just relaxed the requirement of a unique name > in the shared case. > >> That idea also >> came up independently because it was felt it would be better >> conceptually to have different address strings for different shared >> subscriptions on the same topic, given they would essentially be >> different [psudeo-] nodes. > > > Personally I don't like cramming too much stuff into the address string, > especially when there are numerous other explicit fields intended to convey > additional information. > > A 'shared-subscription' link property whose value was the name of the > subscription to use, would be simple and (in my view) clear, and wouldn't > need to fit in with any other grand plans for address syntax. >
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. 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. -- Rob > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
