amqp — archive

[Clemens Vasters <clemensv@microsoft.com>]

The rule is that you can’t say “no” without constructively offering a better alternative :) I know destination isn’t ideal for the exact reason you point out. I think of it as a working term until we find something better that doesn’t clash with “address” or “host”. Von: amqp@lists.oasis-open.org im Auftrag von Alan Conway <aconway@redhat.com> Gesendet: Montag, November 5, 2018 6:09 PM An: Clemens Vasters Cc: oasis-amqp-list Betreff: Re: [amqp] Addressing Model Blog Post Interesting read! I'm in general agreement with the proposed syntax and rationale. But I have a Nit to Pick: "In the OASIS AMQP Technical Committee, we will add the abstract notion of destination into the addressing specification". NOOOooooo! It can't be called a "destination"!! to:( fred.com )/x - sending stuff to a thing in fred - very destination-like source:( fred.com )/y - getting stuff from a thing in fred - NOT A DESTINATION ( fred.com ) could contain targets, sources, request-response servers, named or anonymous relays, who knows what else. It might be reached by opening a TCP connection, accepting a TCP connection, routed intermediaries, sidecars, fabrics, clouds, fogs, bogs or homing pigeons. It is in no sense limited to being a "destination" of anything. (I'm senstive from efforts to bridge bi-directional AMQP to HTTP technologies steeped in unidirectional-client-server assumptions. I really don't want assumptions of directionality in the language of the AMQP addressing spec itself!!!) Not sure what to call this protocol-independent name/identifier/address, but it can't imply one-directional communication: container, node, host, endpoint, thing, object, place, name, moniker, handle, doohicky ... the English language doesn't have enough vague nouns for our industry. On Thu, Nov 1, 2018 at 5:28 PM Clemens Vasters < clemensv@microsoft.com > wrote: I put together a blog post on the considerations behind the proposed addressing model that we discussed on the last call and looking ahead to what a complementing routing spec might cover https://vasters.com/blog/a-new-network/