Let channels be identified by an ID rather than their address. #663

smoya · 2021-12-01T11:39:41Z

Context

This is part of the RFC #618 (comment).
In an effort around reducing the scope of such RFC, it has been split into several proposals so they can move forward independently.

The problem

Channels are currently identified by their address. E.g.:

channels:
  user/signedup: # this is both the address and the identifier of the channel
    description: ...

With the current approach, and once #660 happens, we will have few issues:

When referencing a channel, the channel identifier should match with the refereced one, otherwise the address will be different than in the referenced channel. E.g.:

# common.yaml
channels:
  user/signedup:
      description: ...

# asyncapi.yaml
channels:
  user/signedup: # here we have to use the same identifier as in common.yaml, otherwise the address will be different
    $ref: 'common.yaml#/components/channels/user~signedup'

That introduces a problem when we need to change the address of a shared channel. Let's say Kafka topic name changes. With the current approach, we need to change the address on all files that reference the user/signedup channel from common.yaml (as JSON Reference will fail as well).
As you may noticed, the JSON Pointer for user/signedup channel is user~1signedup. It is unexpected and you have to have some JSON Pointer knowledge or find examples to find out such format. It is very error-prone.

Suggestion

To add a new address field to the channel definition that represents the real address and not the channel identifier.
With that change, the previous example will look like:

# common.yaml
channels:
  userSignedUp:
      address: user/signedup
      description: ...

# asyncapi.yaml
channels:
  myUserSignedUp: # here we can add whatever ID we want. If address changes in `userSignedUp` from common.yaml, nothing will need to change in this file
    $ref: 'common.yaml#/components/channels/userSignedUp' # no slash transformation is needed in the JSON Pointer :)

Fixes #739 as well

The text was updated successfully, but these errors were encountered:

jonaslagoni · 2022-01-19T14:44:09Z

I love the move to a property, whether address is the right keyword, not so sure, but I don't have other alternatives at the moment.

What exactly is the reason we need an ID rather than making channels an array?

Especially now that #665 is added.

smoya · 2022-01-19T17:18:31Z

I love the move to a property, whether address is the right keyword, not so sure, but I don't have other alternatives at the moment.

What exactly is the reason we need an ID rather than making channels an array?

Especially now that #665 is added.

I guess the reason is that we might also allow people to reference channels not only from components but from channels at root level.
Another thing is that you need to differentiate between servers anyway, for example, when generating code or documentation. Let's say I want to generate a websocket client but in the document, two servers are declared. How can I pick up one or another? By it's ID.

jonaslagoni · 2022-01-20T16:59:47Z

Okay I retract my suggestion, you are right.

Especially if you want to define two channels operating over the same address, with slightly different behavior, you would need to add a channelId instead to differentiate them, if we had arrays.

smoya · 2022-02-09T15:40:48Z

The following PR's have been created:

char0n · 2022-02-09T16:29:13Z

Hi everybody,

I was CCed in asyncapi/spec-json-schemas#171, so let me share my opinion as well here. IMHO I can see a couple of problems here:

Components.channels field in defined in following way:

This means that string that forms the key can be arbitrary and doesn't have any semantics. string !== {channel}. The proof lies in following AsyncAPI definition fragment:

components:
  channels:
    channel1:
      description: channel description

channels:
  user/signup:
    $ref: "#/components/channels/channel1"

As you can clearly see, the channel1 is just an arbitrary identifier of the channel and has nothing to do with {channel} (path).

The only place where this is problematic is in following fragment:

channels:
 user/logout:
   $ref: "#/channels/user~1signedup"
 user/signedup:
   description: channel description

But as we now have reusable Components.channels field, this usecase should be discouraged and anything that is intended to be reusable should be in Components.channels. This encourages using best practices and putting stuff where it belongs. IMHO I don't think this proposal is needed (don't hate me:).

magicmatatjahu · 2022-02-09T16:44:49Z

@char0n

But as we now have reusable Components.channels field, this usecase should be discouraged and anything that is intended to be reusable should be in Components.channels. This encourages using best practices and putting stuff where it belongs. IMHO I don't think this proposal is needed (don't hate me:).

Please look at this proposal from point of view person who need to write several AsyncAPI documents and use that same channel in few documents. Of course can make reference by:

$ref: "#/components/channel1"

but then needs to remember that (e.g.) "user/signup" channel address, yes? :) So that PR adds possibility to make more easier the "channels registry" and treats address as channelID :)

Please read #618 proposal to understand why we wanna make it :) Of course "channel registry" is not the only reason, but it is one of many, perhaps the best why it makes sense.

char0n · 2022-02-09T17:20:17Z

Please look at this proposal from point of view person who need to write several AsyncAPI documents and use that same channel in few documents. Of course can make reference by:

@magicmatatjahu I really did that. Where I want to get is to have AsyncAPI spec version where the only required fields are asyncapi and info. That way I can create reusable definitions that only contain stuff that is used in multiple other definition. It would look like this:

reusable.yaml

asyncapi: 2.3.0
info:
  title: reusable document fragment
  version: 1.0.0
components:
  channels:
    channel1:
      description: channel description

Then it will be consumed by other definitions:

definition1.yaml

asyncapi: 2.3.0
info:
  title: definition 1
  version: 1.0.0
channels:
  path/to/channel:
    $ref: "./reusable.yaml/#components/channels/channel1"

definition2.yaml

asyncapi: 2.3.0
info:
  title: definition 2
  version: 1.0.0
channels:
  path/to/channel:
    $ref: "./reusable.yaml/#components/channels/channel1"

This is currently not possible as AsyncAPI.channels field is currently required (this requires small backward compatible change to support) . My opinion on this is influenced by heavy usage of OpenAPI and doing exactly the stuff that I describe here using OpenAPI.

Please read #618 proposal to understand why we wanna make it :) Of course "channel registry" is not the only reason, but it is one of many, perhaps the best why it makes sense.

#618 is super long ;] I'm trying to look at this change introduced in this issue in isolated way. People have full ability to create keys as they seem fit and can use a lot of imagination to come up with the key names that are sometimes exotic. This issue IMHO tries to resolve one particular issue which is resolvable by other means (small change in spec + recommended practices).

magicmatatjahu · 2022-02-09T17:35:33Z

This is currently not possible as AsyncAPI.channels field is currently required (this requires small backward compatible change to support) . My opinion on this is influenced by heavy usage of OpenAPI and doing exactly the stuff that I describe here using OpenAPI.

Please read #618 proposal to understand why we wanna make it :) Of course "channel registry" is not the only reason, but it is one of many, perhaps the best why it makes sense.

#618 is super long ;] I'm trying to look at this change introduced in this issue in isolated way. People have full ability to create keys as they seem fit and can use a lot of imagination to come up with the key names that are sometimes exotic. This issue IMHO tries to resolve one particular issue which is resolvable by other means (small change in spec + recommended practices).

Yeah, exactly, currently it's not possible. Changing it is easy (to make channels options) but we need for that 3.0.0.

Maybe I don't understand the second paragraph (sorry!), but a channel key and an address are two completely different things in my opinion. I understand that the keys may be different, but this should be just "information" for the developer, not for a user reading the documentation. It's a bit like a server url - it may have a different key but url identifies its "uniqueness" and so it is with the channel address.

recommended practices

And this is probably the problem, because it is better to solve this at the level of specification and not through recommended practices. There are things that should be recommended, but if there is an option to fix it in the specification itself, then let's go the second way. As I wrote, currently the problem are references and people then have to remember that a given channel should have a given key in the .channels field (exactly address).

Of course, lets wait for others opinion, but I understand in this way the changes that @fmilas proposed and @smoya introduced :)

magicmatatjahu · 2022-02-09T17:37:50Z

Additionally, one may wonder how to overwrite such an address if we want to have something like a channel but without the address? We can create a Channel Trait Object, just like we have a Message Trait Object and an Operation Trait Object, where address will be optional.

char0n · 2022-02-09T18:33:31Z

Maybe I don't understand the second paragraph (sorry!), but a channel key and an address are two completely different things in my opinion. I understand that the keys may be different, but this should be just "information" for the developer, not for a user reading the documentation. It's a bit like a server url - it may have a different key but url identifies its "uniqueness" and so it is with the channel address.

Don't worry; It's definitely me (not being clear). What I tried to say was this:

asyncapi: 2.3.0
info:
  title: reusable document fragment
  version: 1.0.0
components:
  channels:
    user/signup:
      description: channel description
channels:
  user/signup:
    $ref: #/components/channels/user~1signup

People can still use (and probably will) slashes in keys that represents reusable channels. I do understand the argument thought, that this proposal tries to avoid it as much as possible but is it worth it, given we have Components.channels which already solve this?

The last argument I have is about semantics:

Given definition 1:

channels:
  userSignedUp:
      address: user/signedup
      description: ...

And definition 2:

channels:
  userSignedUp:
      $ref: "./definition1.yaml/#/channels/userSignedUp"

When I change definition 1 to:

channels:
  userSignedUp:
      address: user/loggedout
      description: ...

Then resolution/dereferencing/bundling will still work
But the semantics of what userSignedUp is, has changed
And the channel now represents something completely different

The current status quo of {channel} being key of Channels Object guarantees that things fail fast if unique {channel} identifier changes, because if it changes it's probably an important change.

char0n · 2022-02-10T07:56:21Z

Hi guys,

I was thinking about this some more during the night, and looking at this change through the lens of different persona - as a tooling author (not definition writer) I actually like this change. This changes makes {channel} part of Channel Item Object which makes Channel Item Object self-contained. Currently when Channels Object is parsed into individual Channel Item Object elements, I have to attach to the {channel} (key under which the object is defined, which is very important information) as metadata to the particular Channel Item Object. With this change, maintaining the metadata will no longer be necessary.

And I want to thank you for giving me the opportunity to voice my opinions here (through two different personas - definitions author and tooling author) and sorry for hijacking this discussion a bit.

smoya · 2022-02-10T11:27:51Z

And I want to thank you for giving me the opportunity to voice my opinions here (through two different personas - definitions author and tooling author) and sorry for hijacking this discussion a bit.

Your opinion is super important on this (and also the opinion of anyone interested in the topic). I explicitly pinged you in the PR because I knew you had feedback to provide and most precisely, you were willing to provide it, which to be honest, in my mind, this is just awesome.

So please keep providing feedback around any PR you see because I think this is what it really matters on this community. In my case, whenever I open a new RFC, I'm looking actively for "Noes" rather than "Yes"; for "This is not gonna work" rather than "oh cool LGTM", you know what I mean :).

Thanks for your extremely valuable help here @char0n !

magicmatatjahu · 2022-02-10T11:56:44Z

Feedback (with other point of view) is very important and there are no apologies for it :) The more "no" votes the better because then we know from additional use cases.

Referring to the change itself: I wonder if when we have an address inside a Channel Item Object, shouldn't the .channels shape of the object be changed to a list instead of a dictionary?

asyncapi: 3.0.0
info: ...

channels: 
- $ref: '#/components/channels/someChannel'

Of course components.channels should still have the shape of an object to make references easier. WDYT? 🤔

smoya · 2022-02-10T12:14:25Z

Referring to the change itself: I wonder if when we have an address inside a Channel Item Object, shouldn't the .channels shape of the object be changed to a list instead of a dictionary?

Why wouldn't just look like servers? A map of unique ID => Channel Item Object.

magicmatatjahu · 2022-02-10T12:22:43Z

Why wouldn't just look like servers? A map of unique ID => Channel Item Object.

Currently channels look like servers as Map<string, Channel Item Object | Ref> however I wonder if it make sense if the address is no longer treated as a key but as an internal value. 🤔 Please treat it as an idea.

Of course that suggestion has problem with referencing when you want to make ref to .channels section like #/channels/someChannel.

Benefits:

treat channels as channels available in the application, key is unnecessary and causes only additional boilerplate.
Minuses:
lack of support for references

char0n · 2022-02-10T12:26:37Z

Referring to the change itself: I wonder if when we have an address inside a Channel Item Object, shouldn't the .channels shape of the object be changed to a list instead of a dictionary?

This would IMHO make referencing even more difficult as people often change their specification and reorder stuff to make more sense or to look better. With using list semantics the indexes will change by reordering the internals of the Channels Object.

channels:
  - address: path/to/channel1
  - address: path/to/channel2

Pointer to channe1: JSON Pointer: #/channels/0
vs

channels:
  - address: path/to/channel2
  - address: path/to/channel1

Pointer to channe1: JSON Pointer: #/channels/1

smoya · 2022-02-10T12:30:11Z

I agree @char0n on this. Also I want to emphasize the fact that channels need a identifier. This is key, and one of the reasons behind this change. Read my comment here #663 (comment)

jessemenning · 2022-02-10T14:09:19Z

This is a great discussion and it sounds like a good idea. Any chance we could have a brief real-time discussion of this, either at a v3 meeting or a dedicated tech discussion?

jessemenning · 2022-02-10T14:13:35Z

I would also be interested of the impact of this on #618 , especially the reference between operations and channels, which is proposed to not be a JSON ref. That seems suboptimal to me, from an understanding and tooling perspective.

Why isn't channel a $ref or JSON Pointer? To keep things simple. If you're referring to a channel here, it must be defined in the channels object. If we allow $ref here, it means it can be dereferenced and therefore the channel ID would be lost. To make things easier and more consistent, this field is simply a string with the name of the channel ID.

damaru-inc · 2022-02-10T16:26:19Z

I like this a lot, especially because it'll help reusability, i.e. breaking models down into reusable files.

magicmatatjahu · 2022-02-11T11:50:38Z

@jessemenning

I would also be interested of the impact of this on #618 , especially the reference between operations and channels, which is proposed to not be a JSON ref. That seems suboptimal to me, from an understanding and tooling perspective.

Good point! I think that we have "little" problem here, however proposal proposed in this issue does not contradict the above sentence. If you want to use the operation, you must have a channel defined in the .channels field. We don't use JSON $ref here for a simple reason - the string tells us where to look (in the .channels field) and then we can be sure if the channel exists or not. If we were to use a reference like:

operations:
  sendUserSignedUpEvent:
    channel: 
      $ref: #/channels/someChannel
    action: send

then after dereferencing we have the channel object and not its identifier. To check if a given channel is in the context of the described documentation (in the .channels section) we would have to check deep equality between the object in .channels and the one defined by reference. Hopefully you understand that comparing string == string is much easier than object == object :)

magicmatatjahu · 2022-02-11T13:52:10Z

Of course, referencing can be a problem if we want to treat operations and channels in a registry fashion. Then we have to remember about those keys in the dictionary between files and I wonder if the operation and channel identifiers should be defined inside the object and not outside, but it's my little digression which we should discuss. cc @smoya @fmvilas

fmvilas · 2022-08-25T05:12:29Z

Nope, they'd look like this:

channels:
  channelA:
    $ref: '#/components/channels/channelA'
  channelB:
    $ref: '#/components/channels/ChannelB'

smoya · 2022-08-25T08:26:17Z

What about the following scenario, where two channels have a pointer to the same one?

channels:
  channelA:
    $ref: '#/components/channels/aChannel'
  channelB:
    $ref: '#/components/channels/aChannel'
components:
  channels:
    aChannel: 
      # channel object

both channelA and channelB will be identified as aChannel, but they are actually different channels.

fmvilas · 2022-08-25T08:46:56Z

Is it really a problem? Honest question.

smoya · 2022-08-25T08:55:42Z

Is it really a problem? Honest question.

In my brain, IDs should be unique across a document. So yes, it is a problem in the right moment two different objects share the same id.

fmvilas · 2022-08-25T09:24:52Z

But they don't share the same ID. In your example:

channels:
  channelA:
    $ref: '#/components/channels/aChannel' # --> ID here is channelA
  channelB:
    $ref: '#/components/channels/aChannel' # --> ID here is channelB
components:
  channels:
    aChannel: 
      # channel object  # --> ID here is aChannel

smoya · 2022-08-25T09:29:04Z

But they don't share the same ID. In your example:

channels:
  channelA:
    $ref: '#/components/channels/aChannel' # --> ID here is channelA
  channelB:
    $ref: '#/components/channels/aChannel' # --> ID here is channelB
components:
  channels:
    aChannel: 
      # channel object  # --> ID here is aChannel

As per your comment in #663 (comment), the id will come from the JSON pointer. So it will be:

channels:
  channelA:
    $ref: '#/components/channels/aChannel' # --> ID here is aChannel
  channelB:
    $ref: '#/components/channels/aChannel' # --> ID here is aChannel
components:
  channels:
    aChannel: 
      # channel object  # --> no id unless... manually added?

fmvilas · 2022-08-25T11:48:02Z

Yeah sorry, my fault. It should come from the context when possible, not from the JSON pointer. I think it makes sense to take it from the context, otherwise, why would we bother having channelA and channelB keys inside channels, right?

fmvilas · 2022-08-28T15:43:43Z

If we make it mandatory to put channel definitions inside components/channels and then reference them using their IDs, it would look something like this:

channels:
  - channelA
  - channelB
operations:
  sendSomething:
    action: send
    channel: channelA
components:
  channels:
    channelA: 
      # channel object or $ref
    channelB: 
      # channel object or $ref

The channel ID comes from the context. In this case, from the key in components/channels. Now the question is, do we really need the root channels object? 🤔

Benefits

No $ref everywhere, just IDs.
Shorter and easier to read than $ref.
All definitions are in one place.

Drawbacks

IDs don't look special (like $ref), just plain strings, making it harder to spot at first sight.
Code editors will not understand this is a reference unless we provide support for that ourselves.

If we use $refs, it would look like this:

channels:
  channelA:
    $ref: '#/components/channels/aChannel'
  channelB:
    $ref: '#/components/channels/aChannel'
operations:
  sendSomething:
    action: send
    channel:
      $ref: '#/channels/channelA'
components:
  channels:
    aChannel: 
      # channel object or $ref

Still, the channel ID comes from the context. In this case, from the key in channels and the key in components/channels is just there to allow referencing.

Benefits

Code editors will immediately understand this is a reference.
Parsers will automatically dereference these into objects.
$refs may point to anywhere in the world, not just in this document.

Drawbacks

Longer and harder to read at first sight.
It may be confusing to some that channel IDs are channelA and channelB and it's not actually aChannel duplicated.
$refs may point to anywhere in the world, not just in this document. Can be inconvenient if you want to quickly grasp which URLs this document is pointing to.

smoya · 2022-08-30T18:09:24Z

For the record, I want to raise a problem with our spec that is currently a thing, and that might be possible to fix with the first suggestion @fmvilas made or actually any approach that moves definitions to live under components and be referred from an array of IDs (or JSON Pointers):

servers:
  c: ...
  d: ...
components:
  channels:
    someChannel:
      servers: [c, d] # do we refer to the servers located under components or rather in the root of the document?
  servers:
    c: ...
    d: ...

With Servers becoming an array of Ids, it gets fixed:

servers:
  - c
  - d
components:
  channels:
    someChannel:
      servers: [c, d] # c and d servers refer to servers defined always in components.
  servers:
    c: ...
    d: ...

Also with Servers becoming an array of JSON Pointers:

servers:
  - '#/components/servers/c'
  - '#/components/servers/d'
components:
  channels:
    someChannel:
      servers: [c, d] # c and d servers refer to servers defined always in components.
  servers:
    c: ...
    d: ...

However, we could also fix it by using JSON Pointers for all Ids instead, however you will see that the fact servers is not an array, it introduces uncertainty again:

servers:
  c: # ...
  d: # ...
components:
  channels:
    someChannel:
      servers: 
        - '#/components/servers/c'
        - '#/components/servers/d'
  servers:
    c: ...
    d: ...

derberg · 2022-09-01T11:40:18Z

@smoya regarding your comment about problems with spec and servers. The spec is pretty clear:

The servers on which this channel is available, specified as an optional unordered list of names (string keys) of [Server Objects](https://www.asyncapi.com/docs/reference/specification/v2.4.0#serverObject) defined in the [Servers Object](https://www.asyncapi.com/docs/reference/specification/v2.4.0#serversObject) (a map)

so nobody should expect that ids in an array of servers point to components. Especially that components is just a reuse feature, not an "integral" part of API definition. Stuff in components do not have to be referenced and used in a given API. So I think we are safe.

I have to admit that after holidays it is pretty difficult to catch up with discussion in this issue as I have a feeling there are 2 different but related topics.

And this is why I think there is some confusion in the discussion too.

One topic, original, that @smoya started, about identifying channels by ID -> which makes a lot of sense
Second one that @fmvilas dropped in about changes to operations and how referencing channels should work.

AD1

we should definitely do it 😄
$ref should be supported, and it is not a problem IMHO that ID of the channel does not match the ID of referenced channel data. Why would it be a problem, JSON Pointer is a pointer, not identifier, matching of the ID should not be expected.

As per your comment in #663 (comment), the id will come from the JSON pointer. So it will be:
channels:
channelA:
$ref: '#/components/channels/aChannel' # --> ID here is aChannel
channelB:
$ref: '#/components/channels/aChannel' # --> ID here is aChannel
components:
channels:
aChannel:
# channel object # --> no id unless... manually added?

@smoya you are referring to a comment from @fmvilas but not related to Channel Item Object, but this was about the "referencing of channels from inside the operation" where you do not have a chance to provide Channel ID 👇🏼

operations:
  sendUserSignedUp:
    action: send
    channel:
      $ref: '#/channels/userSignedUp'

so, on regards to Channel Item Object

channels:
  channelA:
    $ref: '#/components/channels/aChannel' # --> channelA is the ID,  not aChannel

AD2

So looking again at

operations:
  sendUserSignedUp:
    action: send
    channel:
      $ref: '#/channels/userSignedUp'

@fmvilas so we are thinking about some solution, that after parsing document and dereferencing, it looks like below, more or less:

x-parser-channel-id: userSignedUp # --> not inside channel, as during dereferencing we would lost that information. We can move it inside channel after dereferencing if needed
channel:
      address: 'user/signedup'
      ...other channel stuff...

and then we have a model function that can return x-parser-channel-id, when I need an ID, right?

if yes, then it doesn't sound as bad as I thought at the beginning. It would be up to parsers to implement their way of getting the channel Id.

I think the most important rule that we have in our contribution guide is consistency. So approach with using $ref for channel inside operation is good, and also using x-parser-channel-id will be consistent with similar solution we have for x-parser-schema-id

am I missing something?

fmvilas · 2022-09-01T14:24:53Z

@derberg no man, I think you're pretty much aligned with the discussion.

so nobody should expect that ids in an array of servers point to components

Well, yeah, I get what you say but also understand Sergio's point of view. Unless you read the whole spec (which is unlikely) you could probably expect these IDs are coming from components. But yeah, nothing really bad and I know we can't be fixing problems for those who don't read docs, right? Especially, when it's a spec.

I think we can agree that referencing using $ref inside operations is a good option. For consistency, we may also want to do the same in channels.[channel].servers? Maybe also inside the SecurityRequirements object? For sure not a discussion for this issue.

magicmatatjahu · 2022-09-01T14:42:57Z

I think we can agree that referencing using $ref inside operations is a good option. For consistency, we may also want to do the same in channels.[channel].servers? Maybe also inside the SecurityRequirements object? For sure not a discussion for this issue.

We can use $ref in every place when we need to refer to something (channel.servers(), operation.channel(), channel.message() etc.), I'm in favour of that ➕ Also idea to change SecurityRequirements shape with using $ref is good for me.

fmvilas · 2022-09-01T14:48:46Z

I created a separate discussion for that topic: #829.

github-actions · 2022-12-31T00:16:04Z

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

fmvilas · 2023-01-10T17:12:41Z

Getting there dear bot. Be patient.

jonaslagoni · 2023-03-09T12:33:09Z

This is already done 🙂

github-actions · 2023-07-08T00:19:42Z

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

smoya · 2023-07-11T08:54:47Z

But please bot do not close it yet until v3 is out 🙏

github-actions · 2023-11-10T00:16:07Z

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

smoya added the 💭 Strawman (RFC 0) RFC Stage 0 (See CONTRIBUTING.md) label Dec 1, 2021

doc-jones mentioned this issue Jan 14, 2022

01-14-2022 Weekly Landscape Report postman-open-technologies/specifications#6

Closed

jonaslagoni mentioned this issue Jan 19, 2022

Work on 3.0 release #691

Closed

smoya mentioned this issue Feb 9, 2022

feat: let channels be identified by ID. Address is now moved into a new field #719

Closed

smoya changed the title ~~Let channels be identified by an ID rather than their address.~~ feat: Let channels be identified by an ID rather than their address. Feb 9, 2022

smoya changed the title ~~feat: Let channels be identified by an ID rather than their address.~~ feat: let channels be identified by an ID rather than their address. Feb 9, 2022

smoya changed the title ~~feat: let channels be identified by an ID rather than their address.~~ Let channels be identified by an ID rather than their address. Feb 9, 2022

smoya mentioned this issue Feb 9, 2022

feat: let channels be identified by ID. Address is now moved into a new field asyncapi/spec-json-schemas#171

Closed

fmvilas mentioned this issue Aug 27, 2022

feat: add new channels object #827

Merged

fmvilas mentioned this issue Aug 29, 2022

Spec 3.0 Meeting, 16:00 UTC Wednesday August 31st 2022 asyncapi/community#443

Closed

fmvilas mentioned this issue Sep 1, 2022

Unify all referencing mechanisms in v3 #829

Closed

github-actions bot added the stale label Dec 31, 2022

github-actions bot removed the stale label Jan 11, 2023

github-actions bot added the stale label Jul 8, 2023

github-actions bot removed the stale label Jul 12, 2023

derberg mentioned this issue Nov 7, 2023

Message ID doesn't exist on reply level asyncapi/parser-js#873

Closed

github-actions bot added the stale label Nov 10, 2023

smoya removed the stale label Nov 10, 2023

smoya closed this as completed Dec 7, 2023

Let channels be identified by an ID rather than their address. #663

Let channels be identified by an ID rather than their address. #663

Comments

smoya commented Dec 1, 2021 • edited Loading

Context

The problem

Suggestion

jonaslagoni commented Jan 19, 2022

smoya commented Jan 19, 2022 • edited Loading

jonaslagoni commented Jan 20, 2022

smoya commented Feb 9, 2022

char0n commented Feb 9, 2022 • edited Loading

magicmatatjahu commented Feb 9, 2022

char0n commented Feb 9, 2022

magicmatatjahu commented Feb 9, 2022

magicmatatjahu commented Feb 9, 2022

char0n commented Feb 9, 2022 • edited Loading

char0n commented Feb 10, 2022 • edited Loading

smoya commented Feb 10, 2022 • edited Loading

magicmatatjahu commented Feb 10, 2022

smoya commented Feb 10, 2022

magicmatatjahu commented Feb 10, 2022

char0n commented Feb 10, 2022

smoya commented Feb 10, 2022

jessemenning commented Feb 10, 2022

jessemenning commented Feb 10, 2022

damaru-inc commented Feb 10, 2022

magicmatatjahu commented Feb 11, 2022 • edited Loading

magicmatatjahu commented Feb 11, 2022

fmvilas commented Aug 25, 2022

smoya commented Aug 25, 2022

fmvilas commented Aug 25, 2022

smoya commented Aug 25, 2022

fmvilas commented Aug 25, 2022

smoya commented Aug 25, 2022 • edited Loading

fmvilas commented Aug 25, 2022

fmvilas commented Aug 28, 2022 • edited Loading

Benefits

Drawbacks

Benefits

Drawbacks

smoya commented Aug 30, 2022

derberg commented Sep 1, 2022

AD1

AD2

fmvilas commented Sep 1, 2022

magicmatatjahu commented Sep 1, 2022

fmvilas commented Sep 1, 2022

github-actions bot commented Dec 31, 2022

fmvilas commented Jan 10, 2023

jonaslagoni commented Mar 9, 2023

github-actions bot commented Jul 8, 2023

smoya commented Jul 11, 2023

github-actions bot commented Nov 10, 2023

smoya commented Dec 1, 2021 •

edited

Loading

smoya commented Jan 19, 2022 •

edited

Loading

char0n commented Feb 9, 2022 •

edited

Loading

char0n commented Feb 9, 2022 •

edited

Loading

char0n commented Feb 10, 2022 •

edited

Loading

smoya commented Feb 10, 2022 •

edited

Loading

magicmatatjahu commented Feb 11, 2022 •

edited

Loading

smoya commented Aug 25, 2022 •

edited

Loading

fmvilas commented Aug 28, 2022 •

edited

Loading