amqp — archive

AW: [amqp] Addressing Model Blog Post

From: Clemens Vasters
To: [email protected]
Date: Wed, 07 Nov 2018 11:41:00 -0000

You may just have convinced me of area (or realm , which is a synonym) We address areas (which may be realized by one or more containers) and then dispatch to nodes inside those areas. Von: Rob Godfrey <[email protected]> Gesendet: Mittwoch, 7. November 2018 12:15 An: Clemens Vasters <[email protected]> Cc: Alan Conway <[email protected]>; oasis-amqp-list <[email protected]> Betreff: Re: [amqp] Addressing Model Blog Post I think of it as more of an area or (address) space than a point or spot (terms which I don't think give the sense that they contain addresses within them). Place is.. . fine... I guess -- Rob On Wed, 7 Nov 2018 at 11:42, Clemens Vasters < [email protected] > wrote: Given that destination has too much of a from here to there directional implication, let s try terms that are only about where you want to messages to go or come from: Place? Spot? Point? A place identifier is a structured name that represents a logical routing source or target. Place identifiers are strings that follow the DNS naming conventions, but places do not have to be registered in DNS and they don t have an associated IP address. They are just names describing logical entities in a system, and the DNS-like structure helps expressing hierarchical relationships. A spot identifier is a structured name that represents a logical routing source or target. Spot identifiers are strings that follow the DNS naming conventions, but spots do not have to be registered in DNS and they don t have an associated IP address. They are just names describing logical entities in a system, and the DNS-like structure helps expressing hierarchical relationships. A point identifier is a structured name that represents a logical routing source or target. Point identifiers are strings that follow the DNS naming conventions, but points do not have to be registered in DNS and they don t have an associated IP address. They are just names describing logical entities in a system, and the DNS-like structure helps expressing hierarchical relationships. Von: Clemens Vasters Gesendet: Montag, 5. November 2018 19:52 An: Alan Conway < [email protected] > Cc: oasis-amqp-list < [email protected] > Betreff: AW: [amqp] Addressing Model Blog Post Container so strongly associated with docker/kubernetes/etc that I consider it a burned term for the time being. Von: Alan Conway < [email protected] > Gesendet: Montag, 5. November 2018 19:49 An: Clemens Vasters < [email protected] > Cc: oasis-amqp-list < [email protected] > Betreff: Re: [amqp] Addressing Model Blog Post On Mon, Nov 5, 2018 at 1:23 PM Clemens Vasters < [email protected] > wrote: The rule is that you can t say no without constructively offering a better alternative :) Rules, rules. I like "container-name" - by analogy with "domain-name" - it is a hierarchical name for a collection of things that might themselves be containers, and may also be name that maps to concrete protocol info (on-ramp info rather than direct IP addresses). I wouldn't mandate that container-name == container-id but that would probably be sensible in some systems. Container is pretty heavily overused but it doesn't feel like it would cause confusion and it is suitably vague. 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: [email protected] im Auftrag von Alan Conway < [email protected] > 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 < [email protected] > 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/ -- _____________________________________________________________________________ Red Hat GmbH, www.de.redhat.com , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill