SourceTask and SinkTask API Optimization suggestions

[sunxiaojian]

1. API版本 0.1.2

2. 问题一：SourceTask和SinkTask API中建议把 init、validate、start合并起来比较好，
   原因是，在用新的api构造插件的时候发现，由于不太清楚init，validate，start的执行顺序，所以就查了一下源码，困惑的是这个调用顺序是怎么样的，但其实写插件的人可能不太关心这个，所以方法多了反而增加了写插件的成本，建议只提供strat接口给用户实现，把validate可以放在配置类加载时实现，init可以留给写插件的人自己抽象；

3.问题二：task、connector、transform都实现了Component 接口，接口中透出了validate方法但实际发现task调用中是没有用到的，如下图:

这样会造成每个实现的sourceTask和sinkTask会有个空方法，造成疑惑，是否可以在SinkTask和SourceTask抽象类中隐去

[odbozhou]

问题1：目前的想法是这样的，validate校验配置，init接受配置，然后start的时候传递上下文信息。这可能是站在熟悉connector的设想。的确在刚接触connector的情况下会有一些困扰，增加了学习成本。我任务适当的调整是可以减少一些困扰的。我的想法是，init和start还是有必要分开切必要的的，这样也比较好理解，init可以用来初始化上线文，配置， 然后再start拿到启动。validate可以作为抽象类中的可选实现而不是接口的必要实现，这样可能对实现着更加友好一些。
问题2：现在的继承关系确实会产生你说的问题，有些实现不会用到，但必须有空实现。你有具体的一些的建议吗？

[sunxiaojian]

关于问题二，可以把validate 空方法 放到 SinkTask和 SourceTask 抽象类中吧，这样在实现这个抽象方法的时候就不会有空方法了，像这样，不用使用者必须实现

[odbozhou]

关于问题二，可以把validate 空方法 放到 SinkTask和 SourceTask 抽象类中吧，这样在实现这个抽象方法的时候就不会有空方法了，像这样，不用使用者必须实现

方便的化，可以把你对connect api的想法提pr到这个仓库吗？
https://github.com/openmessaging/openconnect

[sunxiaojian]

ok，

[sunxiaojian]

问题一描述：

版本 0.1.1 api的定义

版本0.1.2 api定义

差异点： 0.1.1版本是 start是必须实现的，0.1.2版本是init是必须实现的，
问题描述：如果定位是init是初始化配置，那start应该是初始化offset等逻辑的；现在start是不必实现的，对于不了解api的插件扩展者来说可能就不会实现了，这样可能会把初始化客户端和jdbc连接的操作在init里面全部实现了，但是由于在WorkerSinkTask(WorkerSourceTask一样)中的调用顺序是下面如图，在init里面是无法拿到父类SourceTask和SinkTask中的 context 变量的，由于调用顺序的原因，这个值在init的时候应该是空，因为调用顺序造成在init使用这个变量无法实现，这样可能就无法拿到offset等信息，所以实现start方法就成为了必须，但是父类又实现了这个start方法赋值了context，本来是必须要实现的现在做成了可实现可不实现，所以就感觉比较矛盾，所以建议还是0.1.1 api 会比较好一点，总之实现api需要了解调用顺序，建议优化

问题二描述：

pause和 resume 是不是就不要对客户开放了，任务的启停有api就可以了，插件的编写只需要了解如何获取数据和如何offset的就可以了，不应该处理任务的暂停和重启的逻辑，不知这个地方是怎么考虑的？

[lizhiboo]

IMO, SourceTask also needs commit(successMessages) and rollback(failedMessages) interfaces. Besides, we can add a plugin-in mechanism in connect flow for custom logic, such as exception handling for producing message to RocketMQ in SourceConnector.