> Just so I understand exactly what you are saying here. You're saying that > a client sends to "foo" and a consumer received messages sent to "foo". In > order for the consumer to consume from "foo" it passes in either "foo", > "queue:///foo" or "topic:///foo" which determines how the messages are > propagated to the client? "foo" means let the broker decide, > "queue:///foo" and "topic:///foo" mean let the client decide. In addition > to these two approaches, it may be that the protocol itself wants to > decide. MQTT for example, always requires a subscription. > > One way to do this, not straying too far from the original proposal, would > be to make the address uniqueness a combination of the routing type and the > address name. This would allow something like: > > <address name="foo" routingType="anycast"> > <address name="foo" routingType="multicast"> > > We'd need to ensure there is a precedent set for times when a subscriber > just subscribes to "foo". I'd say it makes sense for "multicast" to take > precedence in this case.
That wouldn't work. You would need to change the API to pass in an address type, the protocols to have an address type (in a way it wouldn't be compatible with previous clients). I think this is settled if you make the prefix configurable for cases where users want to have such thing.
