Closed markpeek closed 5 years ago
We have created a CloudEvents programming model / SDK for Extend. Blog and links to the repo are below. The purpose of the SDK is to make it easy for Extend customers to handle and route CloudEvents.
https://goextend.io/blog/cloudevents-support-in-extend
Source code is here: https://github.com/goextend/cloudevents-extend-api
jCloudEvents is in early state and provides a Java API with a CDI bindings:
https://github.com/project-streamzi/jcloudevents/blob/master/introduction.md
@glennblock unless I missed it I don't see yours listed on: https://github.com/cloudevents/spec/blob/master/community/open-source.md - want to add it?
I will add it!
On Fri, Jun 8, 2018 at 4:20 AM Doug Davis notifications@github.com wrote:
@glennblock https://github.com/glennblock unless I missed it I don't see yours listed on: https://github.com/cloudevents/spec/blob/master/community/open-source.md
- want to add it?
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/cloudevents/spec/issues/232#issuecomment-395731422, or mute the thread https://github.com/notifications/unsubscribe-auth/AAInRFavOonu8xUCy18i0sirveQ4LBMXks5t6l4RgaJpZM4Ueub0 .
No existing code, but we're eager to start this.
We're going to invest significant resources in getting some kind of a Webhook + json-format framework off the ground in Kotlin/Java
CloudEvents SDK Design Call Doodle Poll
It seems many Serverless WG/CloudEvents stakeholders are already working on SDKs & libraries to support CloudEvents. We’re hosting a call to discuss this. The goal of this call is to investigate working on a common CloudEvents SDK together, starting with designing an initial scope.
Doodle Poll for call time - https://doodle.com/poll/gcsz53peknxpw4wk
Working Doc - https://docs.google.com/document/d/1JIZxnV_w-dMrSAguG4bqog1vBlD94mm5aFjJlfb-R34
@ac360 good idea! I am also interested, but unfortunately, I am not able to add my name to the GDoc
Matthias Wessendorf - Red Hat
One thing on the SDK is perhaps also integration w/ native event systems. E.g. in Java land, there is CDI, and our current draft / strawman implementation, supports this:
https://github.com/project-streamzi/jcloudevents#receiving-the-event
I think what's also good is that for each platform (e.g. Java), the core be a "core" SDK, defining the Interface and a Builder, and than other modules, such as
cloudevents-amqp
cloudevents-mqtt
that define adapters or builders for interaction w/ some transport protocols (e.g. turn them into AMQP messages, setting the required (prefixed) attributes as AMPQ message properties.
@ac360 mind adding me to the document as interested contributor ?
No code but I would like to get involved in a python version. @matzew the Interface and a Builder makes a lot of sense.
@mateimicu
I started a tiny bit here. https://github.com/williamhogman/cloudevents-python/
Sort of related to #245
@ac360 Regarding the poll - so, it looks like the first option next Monday or Tuesday have the most folks being able to attend
I've extracted (and changed) our Java API and the Builder in a separate repo:
https://github.com/project-streamzi/io.cloudevents/pull/1
It's just a java API for now. I used license headers that are (I guess) compliant to the CNCF headers.
Happy to have this imported somewhere here as well
IMHO, it is a good time to start Runtime Interface Extension for CloudEvents Ecosystem, I am willing to contribute the cloudevents-openmessaging SDK, it is an awesome extension for the serverless in event-sourcing.
Thanks for the input all. We're about to start our first call on this subject in 27 minutes at 8AM PT.
Conference line is here: https://zoom.us/my/cncfserverlesswg
Dispatch is Cloud Events native and uses this golang implementation written by @kars7e: https://github.com/vmware/dispatch/blob/master/pkg/events/cloudevent.go
CloudEvents SDK Sync Call - Proposed Times
Hi all,
Here are the next proposed times for the CloudEvents SDK Sync call: https://doodle.com/poll/aqitqvnmu2mp7txi
In this call, we'll review progress of eachother's SDK implementations and further clarify the scopes of work we outlined in the last call.
Looking forward to chatting with all of you again!
Cheers, Austen
The WIP for Go SDK: https://github.com/dispatchframework/cloudevents-go-sdk. Currently, it implements basic event creation (version 0.1) and HTTP bindings.
Given we've started to work on our SDKs, can we close this issue? @markpeek
I'm going to suggest that we close this one since we've started our SDK work. Please speak up if you think otherwise.
on the call today we agreed to close this issue - we can reopen if new info comes up.
The working group agreed there is a need for common CloudEvents SDK and libraries. This is a placeholder issue for discussion and allow people to include links to any existing code related to handling CloudEvents.