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

Common entry point #120

Closed
bsideup opened this issue Apr 20, 2020 · 5 comments
Closed

Common entry point #120

bsideup opened this issue Apr 20, 2020 · 5 comments

Comments

@bsideup
Copy link
Contributor

bsideup commented Apr 20, 2020

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.

@slinkydeveloper
Copy link
Member

This should be solved by #108, but we'll revisit it after to figure out if we have any leftovers

@bsideup
Copy link
Contributor Author

bsideup commented Apr 21, 2020

@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.

@slinkydeveloper
Copy link
Member

slinkydeveloper commented Apr 21, 2020

As #108

Json and other event formats

To marshal/unmarshal event formats, the user just asks to the EventFormatProvider to provide resolve a format, and the EventFormat implementation takes care of correctly implementing marshal/unmarshal for different event versions (this is highly simplified by the Message interface).

So:

byte[] serialized = EventFormatProvider
  .getInstance()
  .resolveFormat(JsonFormat.CONTENT_TYPE)
  .serialize(input);
CloudEvent deserialized = EventFormatProvider
  .getInstance()
  .resolveFormat(JsonFormat.CONTENT_TYPE)
  .deserialize(input);

HTTP

In sdk v1 there was this concept of Unmarshaller which is removed.

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 Message to read the event from the wire and write to write the event to the wire (naming is still temporary):

VertxMessage msg = new VertxMessage(httpReq);
CloudEvent ev = msg.toEvent();
VertxMessageVisitor res = new VertxMessageVisitor(httpResponse);
event.asBinaryMessage().visit(res);
// or
event.asStructuredMessage(jsonFormat).visit(res);

@slinkydeveloper
Copy link
Member

slinkydeveloper commented Apr 23, 2020

@bsideup does this new API solve the problem, or do you think we still miss something?

@slinkydeveloper
Copy link
Member

To me this one looks solved, reopen if you need it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants