Why a fork? about vmware-go-kcl HOT 2 CLOSED

Thanks for your original contribution on this effort. The code structure are quite different and it also combines with lots of original AWS KCL and Kinesis Connector Library concepts. One major design goal is to make it as close as possible to AWS KCL even using the same constant and parameter names in order to make it easy for cross-referencing on AWS KCL.
I will be happy to contribute back to shard splitting and merging. But I am not sure whether you'd like to accept other changes such as: the structural change.

from vmware-go-kcl.

Thanks @taojwmware for the explanation.

I'm most curious in what you've found using this in production environments. I noticed some changes to not die when non-fatal errors occur during shard allocation, which I've ported but any other issues you have found would be much appreciated to know about so I can address them.

One thing you're missing from this fork is changes I made to avoid race conditions when checkpointing.

I intend to keep the structure in my library as it keeps the godocs clean and easy to read, particularly with the examples

from vmware-go-kcl.