Vincent Chan

首先为1.7的修改点赞, 虽然整体结构作出重大调整令我这边也要996去跟着调，但整体架构往更好方向前进，我认为是值得的。 但有几点我认为仍然可以进一步调整。 首先这个产品的定位我觉得有点问题： 1. 如果是普遍业务的场景完全可以用司空2而不需要定制开发 2. 有定制开发需求的，你们这个产品打包了很多与业务相关的东西，而这些都是不需要的或者不符合定制场景的。业务场景千变万化，你无法适配所有场景，这导致我需要调整你们的源码嵌入我的实际业务逻辑，这样就导致你们修改少还好，你们大调，我也要跟着你们调整，心累。 所以，我期望的是你们管好和设备的通讯就可以了，其他比如workspace，使用什么数据库，使用什么作为缓冲,还有那个Chan的实现都可以通过接口委托出来由客户实现。包括http的调用，你只需要管遥控器内pilot2 app用到的接口即可，其他都不需要，因为只有pilot2 app内的调用我无法控制，其他我都可以控制实现自定义的认证/连接逻辑。 我期望的调整与我使用过程中遇到的问题： 1. spring 2.x -> spring 3.x 变化: integration.IntegrationFlows已被废弃, validation 包已从javax改为jakarta. 这两个问题导致我无法把你们的sdk单独打jar使用，只能把代码cv过来调整。想到后面你们又改，我又要同步代码就心累。 2. cloudapi. AbstractXXXService 应该拆分为两个接口一个用于监听IxxxActivator, 一个用于发送行为IxxxAction, Abstract只需要实现行为部份，监听部份由使用方实现没必要抛UnsupportedOperationException，就算抛应该由使用方抛 3....

> > 老哥 没必要啊，你直接往这里pull requests提交你认为应该改的改动就行了，这样合并后每次要做工作就少了，还能造福其它需要使用上云api的同学 > > sdk可以单独出来，这个demo业务层最好也保留着，持续改进到有司空2的水平那么后面的私有化部署开发就会容易非常多 1. 我的项目已经上spring 3.x了,正如上面所说如果直接pr我项目的修改会使原代码产生大量不兼容变更，作为贡献者我不会破坏原始的基础框架，如果要更新应该由这个项目的持有人进行。 2. 过去，这个demo携带了很多我不需要的东西，我都删除了，这个过程中又添加了很多其他东西再抽出来单独打包成jar给其他项目用，这也导致我很难去pr，除非我连他项目结构都改了(拆分出sdk和demo两个项目)。至少我现在还没方法直接打包他的demo直接引入到我的项目中使用。 3. 我现在能做的就是先在这个项目内写入基础的东西贡献出来，然后再cv到我spring 3的项目再增加一些内部的东西，再打包成sdk给我们其他的项目使用。 这次1.7的发布,sdk那部份和我对

> 你把这个cloud-api-demo 项目当成是一个 网关，使用http来调用这个demo提供的接口。当然，这个demo里很多的代码需要改 如果这样能满足我的业务，我何必搞得这么复杂。有空陪陪孩子不好吗？