OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [amqp] Addressing Model Blog Post




On Mon, Nov 5, 2018 at 1:23 PM Clemens Vasters <clemensv@microsoft.com> 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: 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Â

Â

Â



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]