Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make channels field optional within an AsyncAPI file. #661

Closed
smoya opened this issue Nov 30, 2021 · 12 comments
Closed

Make channels field optional within an AsyncAPI file. #661

smoya opened this issue Nov 30, 2021 · 12 comments
Labels
💡 Proposal (RFC 1) RFC Stage 1 (See CONTRIBUTING.md)

Comments

@smoya
Copy link
Member

smoya commented Nov 30, 2021

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

From #628 (comment):

One way we have seen the specification being used is in a Dictionary type of AsyncAPI document, which is a type of pattern for defining definitions for the common information, shared by each separate application.

However, users have been forced to declare an empty object as a value for the channels field since this is not optional.

Suggestion

To make channels field optional.
It depends on #660, because without it perhaps it won't make a lot of sense.

@smoya smoya added the 💭 Strawman (RFC 0) RFC Stage 0 (See CONTRIBUTING.md) label Nov 30, 2021
@derberg
Copy link
Member

derberg commented Dec 22, 2021

I think this one is pretty easy to push for January 2022 release. Change is small, and I know people use AsyncAPI just to list messages in components, and they do not need channels object and just leave it empty.

@Fannon not sure if you are the one that uses AsyncAPI this way or someone else from SAP? don't remember 😅

@Fannon
Copy link

Fannon commented Dec 22, 2021

@derberg : What do you mean with "this way" excactly?
In the case of using CloudEvents, having channels with topic names may not bean ideal fit because with CloudEvents you would subscribe via "type" or "source" properties. A topic / channel then becomes an implementation detail or may not fit very well.

However, channels still make sense to indicate which events from messages are actually subscribable / actively sent (as opposed to events which are technically supported, but not "active").

If you need any more background, I can get in contact with my colleagues. I'm not working on this directory, but I'm in contact with the colleagues who do.

@derberg
Copy link
Member

derberg commented Dec 22, 2021

oh sorry, so I meant that someone from SAP uses AsyncAPI in a way that channels are just channels: {} and then just messages are listed in components. But yeah, I forgot how big SAP is and that probably it was someone not related to the work that you are doing 😆

this is the case I was talking about asyncapi/parser-js#210

@smoya
Copy link
Member Author

smoya commented Jan 4, 2022

@smoya
Copy link
Member Author

smoya commented Jan 19, 2022

As per asyncapi/spec-json-schemas#146 (comment), we won't include this change in 2.3.0 but rather in 3.0.0.

dalelane added a commit to dalelane/website that referenced this issue Jan 23, 2022
This change (from asyncapi/spec#661) is now being held back to
version 3.0 so I've removed the reference to it from the
release notes for 2.3

Signed-off-by: Dale Lane <dale.lane@uk.ibm.com>
@github-actions
Copy link

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 ❤️

@github-actions github-actions bot added the stale label May 20, 2022
@derberg derberg removed the stale label May 23, 2022
@jonaslagoni
Copy link
Member

jonaslagoni commented Sep 28, 2022

I think we can close this one as it was introduced in #827, or do we wait for implementation as well?

cc @derberg @fmvilas @dalelane

@smoya smoya closed this as completed Sep 28, 2022
@smoya smoya reopened this Sep 28, 2022
@fmvilas fmvilas added 💡 Proposal (RFC 1) RFC Stage 1 (See CONTRIBUTING.md) and removed 💭 Strawman (RFC 0) RFC Stage 0 (See CONTRIBUTING.md) labels Sep 28, 2022
@fmvilas
Copy link
Member

fmvilas commented Sep 28, 2022

Moving to RFC 1. It's still missing JSON Schema and Parser implementations. I'll update the label once it's ready.

I know an RFC 1 should be a pull request but I think we can just make an exception here for now.

@github-actions
Copy link

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 ❤️

@github-actions github-actions bot added the stale label Apr 14, 2023
@smoya
Copy link
Member Author

smoya commented Apr 15, 2023

This issue is still relevant. Should be marked as completed once AsyncAPI v3 gets released.

@github-actions github-actions bot removed the stale label Apr 15, 2023
@github-actions
Copy link

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 ❤️

@github-actions github-actions bot added the stale label Aug 14, 2023
@smoya
Copy link
Member Author

smoya commented Aug 18, 2023

#661 (comment)

@github-actions github-actions bot removed the stale label Aug 19, 2023
@smoya smoya closed this as completed Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💡 Proposal (RFC 1) RFC Stage 1 (See CONTRIBUTING.md)
Projects
None yet
Development

No branches or pull requests

5 participants