On 14 December 2016 at 18:59, Robbie Gemmell <[email protected]> wrote: > On 14 December 2016 at 15:47, Lorenz Quack <[email protected]> wrote: >> Hello, >> >> I was looking at QPIDJMS-220 [1] to see whether we could add >> support for shared subscriptions to the Qpid Broker for Java and >> was wondering about the proposed name of the connection/link >> capability: SHARED-SUBS >> That seems very generic. Considering this is a vendor specific >> extension would a more scoped name be more appropriate? I saw >> that there seems to be precedent [2] for this naming convention: >> APACHE.ORG:SHARED-SUBS >> But then again, if my reading of the code is correct, the QPIDJMS >> client does not seem to follow that naming convention. Is there >> a reason for this? >> > > Keeping it generic was somewhat deliberate, I don't really consider it > to be particularly vendor specific. One reason it exists is to support > a standard mapping to a vendor-neutral API, for example. We could > certainly have called it something like that but I didn't see a > particular need in this case. > >> Another question that came up when reading [1] was the use >> of "global" to describe the namespace for subscriptions without >> clientId. In my mind that is a bit unfortunate because to me it >> suggests something global is also available locally and when >> considering uniqueness you would consider local AND global. >> What it is used for in this context seems to be an anonymous >> namespace in contrast to the ones named by clientId. In other >> words it is a sibling to the other namespaces rather than at a >> different level of the abstract space hierarchy. >> > > To be clear, in the JMS scenario it would only used by clients that > dont have a ClientID set, but non-JMS clients would be free to use > this whenever they like. > > Link names are being used to convey the subscription name information, > and those link names are container-scoped in terms of their > uniqueness, something thats baked into the core spec and doesnt change > with this scenario. The 'global' flag is then being used on top of > this in concert with the 'shared' flag to indicate the subscription > name derived should be applied in a non-container-scoped fashion, such > that all containers doing similarly also access the same subscription, > i.e. it is a globablly accessible subscription rather than jsut > container scoped. This does not remove the need for link names to be > unique per-container however
...to be a little clearer, note I'm talking from view of the 'client' container at this point, given the uniqueness is in a particular direction between two named containers. >, and not violating that is part of the > reasoning for the naming scheme mentioned, to facilitate a way of > using multiple unique link names both for the same subscription or for > different types of subscription with the same subscription name (but > not link names) at the same time. Servers enforcing the appropriate > access to a global/not-global subscriptions based on a given link name > is something listed in the section at the end. > > I actually shamelessly stole that particular name and much of the idea > from a previous semi-unrelated discussion with Gordon. I thought the > name was fairly appropriate to what it is doing personally. > > Robbie > > (This might have been easier to spot as a reply to the thread about > this stuff on the users list) > >> >> Kind regards, >> Lorenz >> >> [1] https://issues.apache.org/jira/browse/QPIDJMS-220 >> [2] https://www.amqp.org/specification/1.0/filters >> >> >> --------------------------------------------------------------------- >> 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]
