Plan for glue-ing core to api
See original GitHub issue- Remove
toBinaryMessage
&toStructuredMessage
implementing the CloudEventVisitor/CloudEventVisitable: #150. This allows all protocol bindings/event formats to continue working - Remove spec version conversion (
toV1()
andtoV03()
) fromCloudEvent
interface: https://github.com/cloudevents/sdk-java/pull/147 - Flatten attributes implementation (this is not required, however it simplifies the code and reduce allocations): WIP from https://github.com/cloudevents/sdk-java/pull/148
- Remove assumption that
CloudEvent
implementsCloudEventVisitable
: This PR will move the code under the default implementation ofCloudEventVisitable
under a genericCloudEventVisitable
implementation forCloudEvent
interface (placed incloudevents-core
) -
cloudevents-core
depends oncloudevents-api
All PRs from 1 to 4 will change the CloudEvent
interface (and friends) inside core in order to make it equal to the one inside api. After this is done, it will be trivial to remove the old interfaces in core and replace them with the ones in api.
Issue Analytics
- State:
- Created 3 years ago
- Comments:11 (11 by maintainers)
Top Results From Across the Web
AWS Glue Pricing | Serverless Data Integration Service
For the AWS Glue Data Catalog, you pay a simple monthly fee for storing and accessing the metadata. The first million objects stored...
Read more >FPGA - logicdev.eU
We expertise in a wide variety of configurable core, high-speed transceivers, ... with Co-planning on Stimuli, test bench, and measurement technique.
Read more >Writing Clean Code in ASP.NET Core with Dependency ...
When looking at code to evaluate its coupling, remember the phrase “new is glue.” That is, anywhere you see the “new” keyword instantiating...
Read more >Invoking glue job via .net core 3.1 sdk : Internal service error ...
Describe the bug Hi, We have a lambda that is participating in a step function which invokes various glue jobs during individual executions...
Read more >How to optimize Spark's performance and reduce the cost of ...
AWS Glue, a managed serverless ETL service provided by Amazon Web Services ... If one uses a dataframe or dataset API, the execution...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
If there’s agreement on those 3 points, I’m wondering if we can split this into pieces and first focus on getting to those 3 end-goals… regardless of how we get there. Meaning, I believe that Pivotal’s main concern is that the ‘api’ layer remain clean, so we can focus on retaining that while also ensuring ‘core’ properly uses ‘api’ (e.g. doesn’t duplicate the CE interface).
The 2nd part would then be to discuss the ‘core’ layer. While we may not have 100% agreement on the exact steps outlined by @slinkydeveloper’s in the first comment, it should lay the foundation by cleaning up the code base and getting us out of the WIP stage we’re in now. Then, since I’m pretty sure we don’t have agreement yet on the design of ‘core’, we can at least then discuss any possible redesigns w/o worrying about ‘api’ and w/o mixing up any ‘clean-up’ steps that need to happen right now.
I realize this means that Pivotal will probably not use ‘core’ in the near term, but I’m hoping they’ll continue to help in any redesign so they can use it in the not too distant future. But in the meantime, this should free the ‘api’ layer from any lingering clean-up items so they can at least use that safely.
Thoughts?
I can’t speak to whether the steps listed in the first comment are in the right order, or whether they’re the minimal set, but I do have a question… from my reading of the comments it appears that there is agreement that at the end of this process we should: 1 - Not have the CloudEvent interface in ‘core’ 2 - ‘api’ should have the only definition of the CloudEvent interface (‘api’ might have other interfaces defined, but I’m just focusing on the CloudEvent one) 3 - ‘core’ should depend on ‘api’
Is that correct?