-
-
Notifications
You must be signed in to change notification settings - Fork 75
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
[docs:] Add conventions for bindings #70
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love the direction this is taking, @iancooper. I think some things related to publish
meaning "we receive" and subscribe
meaning "we send", will be solved soon ™️
Have a look at this video where Lorna and I discuss potential solutions for the publish/subscribe challenge: https://www.youtube.com/watch?v=YixYuYCmyJs.
Conventions.md
Outdated
A Binding may also be used by the providers of SDKs for MoM to provide metadata to configure producers or consumers using that SDK. That is outside the scope of advice here, but SDK owners wishing to use Bindings may follow the general advice here. | ||
|
||
## Effective Bindings | ||
### **Item 1** Use the Extensions Format |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still experimental. I'd not recommend this yet. Maybe we should just advise using Specification Extensions: https://github.com/asyncapi/spec/blob/master/spec/asyncapi.md#specificationExtensions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be useful to adopt something that allowed us to provide a consistent format for a binding, other than just JSON, particularly around tooling.
I really like this. |
Apologies all, wei/pull seemed to kill the PR when it updated my fork of bindings. I didn't appreciate that it does not seem to be playing nicely with a PR from master on my fork. I'll close this PR and use #75 @fmvilas I'll see if I can figure out how to pick up your valuable changes and re-apply them |
All I have raised a new PR that should not break when wei/pull syncs my fork, updated for @fmvilas comments. So I will close this PR, please use the other one. Apologies |
Description
This establishes a set of conventions to use when designing bindings. The goal is that bindings should be consistent, such that they can be easily interpreted by tools. 'See #62` for an outline of this problem.
The conventions are listed as a series of items. The intent here is that items could be added (or retired) by the community as we discover better ways to work.
I don't expect that everyone will agree with these conventions, but I do believe that the points here are worthy of community agreement on a convention. I don't believe that this list is complete, but I do believe it is a "good start" for discussion around the conventions we need.
Related issue(s)
'Resolves #62`