[docs:] Add conventions for bindings#70
Conversation
There was a problem hiding this comment.
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.
fmvilas
left a comment
There was a problem hiding this comment.
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.
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.
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`