Thanks for the responses to my questions on what we should do about the meaning of noLocal with shared topic
subscriptions (which was listed in A.3.2 as an unresolved issue):
[snip]
>
> So I think we have the following options:
>
> 1. Do nothing. The definitions we have now are the best we can get, and should stay. This is the default option.
>
> 2. Amend the current definitions of noLocal. I have no proposals, but if anyone else feels we should consider this
> please make a proposal.
>
> 3. Drop noLocal from shared subscriptions (both durable and non-durable). We should choose this feature if we think
> noLocal has no useful purpose with shared subscriptions. Note that making this choice doesn't prevent us adding noLocal
> in the future.
Chris Barrow voted 3
John Archibold voted 3
Rob Davies voted 3
(I hope I didn't miss anyone)
John observed "Given that the intended use of noLocal was for a client that wanted to broadcast messages on a topic and
listen for other broadcasts on that topic without hearing its own messages (e.g. a simple group chat model), I vote for
option 3, to drop the use of noLocal from shared subscribers. I don't see an useful intersection between the two."
Chris wrote: "I would vote for option "3. Drop noLocal from shared subscriptions (both durable and non-durable)",
because I can't think of a use case, and I think it would simplify the API. As it stands, the behavior (although
carefully described) is hard to understand, and moreover, I think the less we rely on client IDs the better!"
I am also in favour of 3. My experience in attempting to define what the behaviour should be has made me think that this
is a contrived and unnecessary feature.
I am going to take this as a consensus that the noLocal parameter doesn't have a useful purpose with shared
subscriptions and that we should drop it as a feature.
The noLocal parameter will remain for non-shared subscriptions (i.e. no change to the JMS 1.1 methods).
This is now a final call for views before I go ahead and drop this feature.
Nigel