Qualifying-protocols-and-encodings.md #254
Conversation
| and largely in parallel to the evolution of the aforementioned standards stacks. | ||
|
|
||
| The CloudEvents effort shall not become a vehicle to even implicitly endorse | ||
| or promote project- or product-proprietary protocols, because that were |
|
|
||
| For a protocol or encoding to qualify for a core CloudEvents event format or | ||
| protocol binding, the protocol must either have formal status as a standard | ||
| with a widely-recognized multi-vendor protocol standardization body (W3C, IETF, |
There was a problem hiding this comment.
add "e.g." to the list so people know its not just those.
|
Just a few tweaks, but overall LGTM. Once/if we get the primer doc added I think this would be good to be included in there instead of as a stand-alone doc. |
|
Clemens, I remember you mentioned in last week's call something like the protocol has to be implemented by 3 separate parties which I think makes the qualification more quantitative. Any reason it's not mentioned here? |
| The explicit goal of the CloudEvents effort, as expressed in the specification, is | ||
| "describing event data in a common way" and "to define interoperability of event | ||
| systems that allow services to produce or consume events, where the producer and | ||
| consumer can be developed and deployed independently". |
There was a problem hiding this comment.
Technically you get this just using and agreed upon messaging queue. Cloud events is suppose to be for transportability for the workload so you can switch out the producer and not change your consumer code.
There was a problem hiding this comment.
If we want to wordsmith this text then we should do it in the original spot, primer.md, first.
|
All, please review this for Thursday's call. Even though @clemensv didn't make the suggested edits, if the WG agreed to the overall PR (and the edits) then we could do it for him while he's out. They're pretty non-controversial syntax tweaks. |
| working group agrees that the specification will be of sustained practical benefit | ||
| for any party that is unrelated to the product or project from which the protocol | ||
| or encoding emerged. A base requirement for this is that the protocol or encoding | ||
| is defined in a fashion that allows alternate implementations independent of the |
There was a problem hiding this comment.
I am not sure why we stick with qualitative descriptions instead of a quantitative one.
There was a problem hiding this comment.
Do you mean the number of people using it? If so then I think the defacto standard sentence above covers it, no?
There was a problem hiding this comment.
Here is another shoot a this given the various inputs from the conference call
For a protocol or encoding to qualify for a core CloudEvents event format or protocol binding, it must belong to either one of the following categories
- The protocol has a formal status as a standard with a widely-recognized multi-vendor protocol standardization body (e.g. W3C, IETF, OASIS, ISO)
- The protocol has a "de-facto standard" status for its ecosystem category which means it is used so widely that it is considered a standard for a given application. Practically, we would like to see at least one open source implementation and at least a dozen independent vendors using it in their products/services.
There was a problem hiding this comment.
I think if you add e.g. before the "W3C" to make it clear that the list isn't exclusive then it looks ok to me.
I assume this proposal will replace line 31 thru 35, right?
What do other people think of this alternative text?
There was a problem hiding this comment.
consider a definition of "de-facto" standard as "has an open source implementation and is in use by services or products from independent vendors"
There was a problem hiding this comment.
There are other standards. Adding "e.g." is good. I think we need to define the de-facto standard more clearly.
There was a problem hiding this comment.
we could consider linking to someone else's definition: http://www.linfo.org/de_facto_standard.html
There was a problem hiding this comment.
Incorporating @nerdyyatrice's comment as-is
|
@clemensv see if you're ok with @nerdyyatrice's edits All - please look this over in prep for next week's call. I believe the group was ok with the general direction, there was just an desire twiddle the formatting of the "list of requirements", so it should be an easy one. |
| The explicit goal of the CloudEvents effort, as expressed in the specification, is | ||
| "describing event data in a common way" and "to define interoperability of event | ||
| systems that allow services to produce or consume events, where the producer and | ||
| consumer can be developed and deployed independently". |
There was a problem hiding this comment.
I believe for the group to achieve its goals it may want to look at a single encoding and transport protocol for all producers. Say JSON and HTTP 1.1 / 2 (Although true push for eventing may provide some challenges). This way would provide a least common denominator and consistency across cloud providers and ecosystems. This is a MUST to honor the spec.
For specialized consumers that prefer different encodings or transports, they could be referenced here based on status and use in the ecosystem.
Any provider could produce events in different encodings and transports, but to be compliant they must produce via HTTP and JSON (Or whatever the chosen encoding and transport shall be).
There was a problem hiding this comment.
@derekcollison could you open an issue for your idea? I'd like to track it separately from this PR because I think it applies regardless of whether or not we define a "bar" for new encodings/transports (this PR). Do I have that right?
|
LGTM thanks @clemensv @nerdyyatrice |
Signed-off-by: Clemens Vasters <[email protected]>
Signed-off-by: Clemens Vasters <[email protected]>
…standards org clause Signed-off-by: Clemens Vasters <[email protected]>
Signed-off-by: Doug Davis <[email protected]>
|
Approved on 8/16 call. Also approved to move it into the primer. |
* Qualifying-protocols-and-encodings.md Signed-off-by: Clemens Vasters <[email protected]> * updating per discussion in the PR Signed-off-by: Clemens Vasters <[email protected]> * Adding open source organization clause for equivalence with protocol standards org clause Signed-off-by: Clemens Vasters <[email protected]> * move into the primer Signed-off-by: Doug Davis <[email protected]>
Per last week's discussion, a proposal for which protocols and encodings are eligible for inclusion in the core set of Cloud Events specifications.
The top priority here must be to drive interoperability, and we don't get that by promoting dozens of underlying application protocol choices.