-
Notifications
You must be signed in to change notification settings - Fork 5
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
Provide Message Based Cloud Event Emitter (maybe Kafka) #2
Comments
Apache Pulsar and GCP PubSub would be more interesting to my case but Im sure its a minority position compared to Kafka. |
I would like to take this up |
@tomdavidson @masterskipper sounds good to me.. I am wondering how the integration will work out.. as we should be able to support all of them if we have a plan for how the extension will work. I am happy if you guys want to work together on that. |
@masterskipper I would recommend listing the steps that you are planning to do before spending time in coding or sending PRs, so we can review it together. |
@salaboy From the description, the problem statement is not quite clear to me. Looks like event routing needs to be made flexible ( not sure what are high level requirements ). |
can you confirm the requirement?
|
@masterskipper let's define the requirements here for clarity:
The scope for this issue is to provide a Cloud Event Message-Based emitter that can send Cloud Events via Kafka, using probably Spring Cloud Streams to achieve that. This needs to work with the Knative Broker as the HTTP version is doing. We cannot add Kafka dependencies straight into this project, which means that we will need to create a separate project (maven module) for the integration that can be added optionally to the cloud event router fat jar. My suggestion will be to start by adding those dependencies to this project and then we split it up when it is working. Hopefully, that makes sense, if not please feel free to add questions. |
The Cloud Event Router should provide an extension to be able to receive Cloud Events using different transports. Kafka might be a first good candidate.
The text was updated successfully, but these errors were encountered: