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 <rgodfrey@redhat.com>
Gesendet: Mittwoch, 7. November 2018 12:15
An: Clemens Vasters <clemensv@microsoft.com>
Cc: Alan Conway <aconway@redhat.com>; oasis-amqp-list <amqp@lists.oasis-open.org>
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
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.
âContainerâ so strongly associated with docker/kubernetes/etc that I consider it a burned term for the time being.
Von: Alan Conway <aconway@redhat.com>
Gesendet: Montag, 5. November 2018 19:49
An: Clemens Vasters <clemensv@microsoft.com>
Cc: oasis-amqp-list <amqp@lists.oasis-open.org>
Betreff: Re: [amqp] Addressing Model Blog Post
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â.
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.
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
--
_____________________________________________________________________________
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
|