Having differing prefixing schemes across vendors will add complexity to the client, and particularly in cases where an application might connect to two or more different AMQP implementations having different prefix strings or regex expression to manage.
More dirty laundry users won't want to have to deal with and are likely to struggle with to get right. Obtaining custom prefixes wrapped in a centrally administered connection factory (or possibly provided by the broker implementation during the Open performative exchange?) would at least have the benefit of shielding the app from this complexity. If we are leaning towards option #3 route I'm with Shawn though about biting the bullet and trying to standardize on a single prefix convention without further complicating the specification and in turn client and broker implementations having to accommodate this variability. Looking at option #2, annotations could provide a standard, consistent way of indicating destination type ("to" and "reply-to"), irregardless of the address syntax per vendor, and also not have to expose any of this complexity either in app code or in configuration.
Robbie indicated this won't work because existing client and intermediaries wouldn't likely understand these attributes. Wouldn't we assume since the JMS mapping is not yet finalized that any vendors that went out on the limb and built implementations ahead of the game might have to change to conform to the final specification, and therefore any clients/intermediaries would have to change to support the defined annotations/capabilities ?
. . . Or the above if we standardized on a single prefix scheme? Another thing to think about is how this will impact the interaction between JMS and non-JMS clients and what would be reflected to non-JMS clients from the interface point of view.
Neither is ideal and fully transparent.
A non-JMS client would be exposed directly to the mangled name and have to deal with parsing that (and would need to be aware the other side is a JMS client to know it needs to do the parse, and, "how do I find the proper regex expression to use?").
Using the option #2 annotations approach would require the client to gain access to the particular field and decipher the dest type.
Again, option #2 might be less ugly by having a consistent attribute to look for that indicates dest type irrespective of what shows up in the address field, and possibly it would make sense having a more generic field name for this (i.e. "x-opt-dest" instead of "x-opt-jms-dest" - that way a non-JMS client could set dest type when it wants to communicate dest-type scope without necessarily assuming a JMS broker). Mark
