Kevin_T

Does the `Redis API` need to be defined in the `proto` file? We have tried to define the interface of `Redis API` on [capa-java](https://github.com/capa-cloud/cloud-runtimes-jvm/tree/develop/cloud-runtimes-api/src/main/java/group/rxcloud/cloudruntimes/domain/nativeproto/redis) before, mainly referring to `jedis`, but...

> I read your code and it's very good. Could u give some examples on "jedis custom objects which are very complicated"? By the way, did you already use these...

以下是使用到的"非常复杂的jedis自定义对象”： [NativeGeoCommands.java](https://github.com/capa-cloud/cloud-runtimes-jvm/blob/develop/cloud-runtimes-api/src/main/java/group/rxcloud/cloudruntimes/domain/enhanced/redis/NativeGeoCommands.java) ```java import redis.clients.jedis.GeoCoordinate;
 import redis.clients.jedis.GeoRadiusResponse; 
import redis.clients.jedis.GeoUnit;
 import redis.clients.jedis.params.geo.GeoRadiusParam; ``` [NativeHashCommands.java](https://github.com/capa-cloud/cloud-runtimes-jvm/blob/develop/cloud-runtimes-api/src/main/java/group/rxcloud/cloudruntimes/domain/enhanced/redis/NativeHashCommands.java) ```java import redis.clients.jedis.ScanParams;
 import redis.clients.jedis.ScanResult; ``` [NativeKeyCommands.java](https://github.com/capa-cloud/cloud-runtimes-jvm/blob/develop/cloud-runtimes-api/src/main/java/group/rxcloud/cloudruntimes/domain/enhanced/redis/NativeKeyCommands.java) ```java import redis.clients.jedis.SortingParams; ``` [NativeListCommands.java](https://github.com/capa-cloud/cloud-runtimes-jvm/blob/develop/cloud-runtimes-api/src/main/java/group/rxcloud/cloudruntimes/domain/enhanced/redis/NativeListCommands.java) ```java import redis.clients.jedis.BinaryClient; ``` [NativeSetCommands.java](https://github.com/capa-cloud/cloud-runtimes-jvm/blob/develop/cloud-runtimes-api/src/main/java/group/rxcloud/cloudruntimes/domain/enhanced/redis/NativeSetCommands.java)...

@azhsmesos Hi~ 您说的是关于事务消息API的设计思路对么~ > 但是感觉对业务侵入性比较大 我不是很清楚事务方面有没有更简洁易用的api呢，但感觉侵入性越大越难可移植呢 或许也可以参考一下dapr的一个提案中对transaction的设计：https://github.com/dapr/dapr/issues/3354 

以实际使用来说，当把`application_id`传入`configurationSetName`时，这几个参数就足以在AWS SES上进行email发送了

其他关于参数的讨论见：https://github.com/mosn/layotto/issues/715

> 关于“移植性” > 我理解是有这种需求的，比如一套监控系统，部署到阿里云的时候，想发warning邮件得调阿里云的 email 服务，部署到aws的时候得调 aws 的邮件服务…… 是的，我应该写错了，这种场景应该是存在的。

> 附件需字段要吗？我看腾讯云和aws里面有附件字段。 我不太清楚，你们会有这样的场景么。我目前接触到的和了解到的，这套api主要是做notify用的，如果有复杂内容，一般是给个url链接，然后可以跳转到对应云产品的页面进行查看。 是会有一些发送数据分析/数据报表的email，但这些一般都是有个单独的服务/平台，去计算出来。 像一个专家系统，可能这类系统会自己去对接某个云的email服务，并深度使用它的sdk/api。 这种一般应该是个独立的服务，应该也不存在跨语言的问题。

> 关于 metadata > 能否先不添加 metadata ，感觉这个是万恶之源 😢 我觉得也是....之前似乎讨论过，我们可以设计一个 "全集" 的notify api。 > 关于 id 和 application_id 和 邮件模板ID > 能否介绍下这三个字段的区别，是不是说 application_id 就是 邮件模板ID？ 是这样想的： `id`可以理解为一个场景的id，一个应用比如可能有3种email场景，那接入方只传入id=1/2/3即可，其他参数可以自动获取。 因为email的特征是，像以下这些参数，基本不太会变动，所以没必要让接入方每次都传入一大堆参数才能发出去email。 传个id就可以了，再从configuration等地方，获取对应的配置即可。（这样还可以实现热更新的逻辑） ```json {...

> 如果担心 api里字段太多、让用户困惑，那可以拆成多个方法，比如: 就是saas api，还是往 "全集" 的方向走是么。 毕竟这些api，都是弱移植性的，用户用起来也不太会改了。 那这样，拆成几个语义更加清晰的方法，似乎比追求通用性，差异字段放在metadata中更好，更易用。 我也认同这个思路，那看起来： + 需要把这套api拆成几个常用的场景的子api。 + 去除metadata，把参数放到子api的参数定义中。 + 标明，每个子api，所支持的云email服务。