能否只提供通信的sdk

[witcom]

能否只提供通信所需的最小化sdk，不需要任何与通讯无法的逻辑。 sdk只需要负责发送指令到机场/无人机的接接口与接收机场/无人机上报的消息，以及定义好所有交换协议就可以了。 不需要连接任何储存，不需要任何业务逻辑

ps: 代码逻辑混乱，跨模块/跨包交叉调用，该出接口的不出接口，不用出接口的照本宣科一堆无意义的ServiceImpl, 就service懂得出接口隔离？发送，接收,储存就不懂与业务逻辑隔离?, 交换协议(dto,receive)内嵌服务调用及使用lombok使其难以提取到独立模块使用。

[xueshuai0922]

加1，太乱了！

[zhang7249]

能否只提供通信所需的最小化sdk，不需要任何与通讯无法的逻辑。 sdk只需要负责发送指令到机场/无人机的接接口与接收机场/无人机上报的消息，以及定义好所有交换协议就可以了。 不需要连接任何储存，不需要任何业务逻辑

ps: 代码逻辑混乱，跨模块/跨包交叉调用，该出接口的不出接口，不用出接口的照本宣科一堆无意义的ServiceImpl, 就service懂得出接口隔离？发送，接收,储存就不懂与业务逻辑隔离?, 交换协议(dto,receive)内嵌服务调用及使用lombok使其难以提取到独立模块使用。

你把这个cloud-api-demo 项目当成是一个 网关，使用http来调用这个demo提供的接口。当然，这个demo里很多的代码需要改

[xiamo6666]

+1 demo太乱了

[DJIsean]

https://github.com/dji-sdk/DJI-Cloud-API-Demo/commit/d68e3d3eaea8b387de9760472e6ff730633bf805 感谢各位的建议，我们会逐步完善的，有问题麻烦多指出。

[witcom]

首先为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. ServicesPublish 应该返回CompletableFuture 重试与超时机制应包在publish外层或让使用方自己实现
4. swagger不要放到sdk里面，原因与lombok一样，你一个项目用了污染别人整个项目都要加这个依赖才能编译
5. SDKManager 可以通过接口委托出来由使用方决定采用什么策略储存
6. IHttpXXXService 只需要1个,就是pilot2 app里面用的的就足够了（ps: 因为我主要接机场，在之前的版本我已拦截了app内所有调用地址自己实现了，并且swagger污染了依赖，所以sdk内IHttpXXXService我全删了没细看有没有非app内调用的地址)
7. Chan这个东西我之前自己实现的原理是建立一个CommandBarrier的接口委托出去由使用方实现的。至于采用什么策略由使用方决定
8. 在publish前一刻(在ServicesPublish或MqttGatewayPublish) 提供一个发送前的钩子接口, 这个接口用于可以在发送前最后决定/修改发送内容或者记录发送信息到仓存
9. publish的可选配置如bid,tid,retry,timeout应该采用Consumer参数交出来由使用者决定填或不填

[pigeon2049]

首先为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. ServicesPublish 应该返回CompletableFuture 重试与超时机制应包在publish外层或让使用方自己实现
4. swagger不要放到sdk里面，原因与lombok一样，你一个项目用了污染别人整个项目都要加这个依赖才能编译
5. SDKManager 可以通过接口委托出来由使用方决定采用什么策略储存
6. IHttpXXXService 只需要1个,就是pilot2 app里面用的的就足够了（ps: 因为我主要接机场，在之前的版本我已拦截了app内所有调用地址自己实现了，并且swagger污染了依赖，所以sdk内IHttpXXXService我全删了没细看有没有非app内调用的地址)
7. Chan这个东西我之前自己实现的原理是建立一个CommandBarrier的接口委托出去由使用方实现的。至于采用什么策略由使用方决定
8. 在publish前一刻(在ServicesPublish或MqttGatewayPublish) 提供一个发送前的钩子接口, 这个接口用于可以在发送前最后决定/修改发送内容或者记录发送信息到仓存
9. publish的可选配置如bid,tid,retry,timeout应该采用Consumer参数交出来由使用者决定填或不填

老哥 没必要啊，你直接往这里pull requests提交你认为应该改的改动就行了，这样合并后每次要做工作就少了，还能造福其它需要使用上云api的同学

sdk可以单独出来，这个demo业务层最好也保留着，持续改进到有司空2的水平那么后面的私有化部署开发就会容易非常多

[witcom]

老哥 没必要啊，你直接往这里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那部份和我对<1.5的修改已经大差不差了，我只要把协议cv过来删小量东西再适配到我的接口就可以用了，所以1.7的调整我认为很好的。至于细节的处理我认为需要把更多的实现策略交由用户实现/配置是比较好的，你可以提供默认实现/配置，但不要抹煞用户的决策权。而且作为sdk，使用的外部依赖应该越少越好(协议去掉了lombok😊, 又整个swagger来😭)

[witcom]

你把这个cloud-api-demo 项目当成是一个 网关，使用http来调用这个demo提供的接口。当然，这个demo里很多的代码需要改

如果这样能满足我的业务，我何必搞得这么复杂。有空陪陪孩子不好吗？

[Daixingdeng]

确实 封装sdk就不要参与业务编码了 这样很难兼容升级 太心累了