Plan for glue-ing core to api

1. Remove toBinaryMessage & toStructuredMessage implementing the CloudEventVisitor/CloudEventVisitable: #150. This allows all protocol bindings/event formats to continue working
2. Remove spec version conversion (toV1() and toV03()) from CloudEvent interface: https://github.com/cloudevents/sdk-java/pull/147
3. 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
4. Remove assumption that CloudEvent implements CloudEventVisitable: This PR will move the code under the default implementation of CloudEventVisitable under a generic CloudEventVisitable implementation for CloudEvent interface (placed in cloudevents-core)
5. cloudevents-core depends on cloudevents-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.

[duglin]

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?

[duglin]

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?