-
Notifications
You must be signed in to change notification settings - Fork 160
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
Common entry point #120
Comments
This should be solved by #108, but we'll revisit it after to figure out if we have any leftovers |
@slinkydeveloper could you please describe here (in text and/or code snippets) how do you plan to solve it? I believe it will help to define the migration path for those who are already on v1 and need to plan it now. |
As #108 Json and other event formatsTo marshal/unmarshal event formats, the user just asks to the So:
HTTPIn sdk v1 there was this concept of Now the APIs to marshal/unmarshal back/forth the wire resembles the one from sdk-go/sdk-rust, but leveraging generics. Now an HTTP implementation (let's take Vert.x as example) implements the interfaces
|
@bsideup does this new API solve the problem, or do you think we still miss something? |
To me this one looks solved, reopen if you need it |
Since the spec evolves, new versions of the spec are being added (think 0.2, 0.3, 1.0)
At the moment, it is the responsibility of the end user - to figure out from the input (e.g. HTTP request) which spec version was used to encode the event before calling the unmarshaller.
It feels that this (not trivial) responsibility should be handled by the SDK itself and provide a generic method to "just read the CloudEvent", that will read the headers (or parse the JSON object if in structured mode) and figure out which implementation should be used.
This way, adding a support for a newer version of the spec should be as easy as updating the SDK dependency.
The text was updated successfully, but these errors were encountered: