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

Server Object host field compatibility with protocols #1016

Open
smoya opened this issue Feb 1, 2024 · 3 comments
Open

Server Object host field compatibility with protocols #1016

smoya opened this issue Feb 1, 2024 · 3 comments
Labels
❔ Question A question about the spec or processes

Comments

@smoya
Copy link
Member

smoya commented Feb 1, 2024

Recently we got a question in our Slack regarding a particularity on ibmqp binding. The question lead to checking that specifying a CCDT connection file should be possible in v3:

asyncapi: 3.0.0
info:
  title: Test
  version: 0.1.0
servers:
  production1:
    host: 'http://my-ccdt-json-file/'
    protocol: ibmmq
  production2:
    host: 'file://myccdt.json/'
    protocol: ibmmq

As you can see, the host includes the protocol converting it to a URL, something I understand not expected in v3 or even somehow illegal. The URL in rendered docs look like ibmmq://http://my-ccdt-json-file/ and ibmmq://file://myccdt.json/ respectively.

The question is, should a URL be allowed as a value for the host field? The spec doesn't mention anything about. Not even a "the host field should not be a URL".

Whatever direction we take, we should clarify what the host is expected or not to include.

Slack thread: https://asyncapi.slack.com/archives/C0230UAM6R3/p1706705627052239

@smoya smoya added the ❔ Question A question about the spec or processes label Feb 1, 2024
Copy link

github-actions bot commented Jun 1, 2024

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 Jun 1, 2024
@smoya smoya removed the stale label Jun 5, 2024
@smoya
Copy link
Member Author

smoya commented Jun 5, 2024

@fmvilas
Copy link
Member

fmvilas commented Jun 8, 2024

Isn't it one of these cases where a subprotocol would work? For instance:

asyncapi: 3.0.0
info:
  title: Test
  version: 0.1.0
servers:
  production1:
    host: 'my-ccdt-json-file/'
    protocol: ibmmq+http
  production2:
    host: 'myccdt.json/'
    protocol: ibmmq+file

To me, this is similar (if not the same) as with WebSocket + MQTT/STOMP/others.

We should probably define the meaning of this structure protocol[+subprotocol].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
❔ Question A question about the spec or processes
Projects
None yet
Development

No branches or pull requests

2 participants