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, 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]
