Kevin_T

> 关于”如何在没有 delay queue 的云环境模拟 delay queue“ 这个有点麻烦，属于给 MQ 加新 feature，一期可以先不管这个吧？ Hi，我同意。因为我们这边有这个需求所以才做的，社区一期先忽略这个吧，可能后面再考虑。

OK，需要我去dapr提个案讨论一下吗

最近比较忙，如果社区还没有提的话，我本周去dapr提案

Hi，我之前在capa项目中调研过一些Redis的API，可以作为参考 如 https://github.com/mosn/layotto/issues/530 ，在capa中我使用java接口进行api定义，主要参考了 http://redisdoc.com/index.html 文档和jedis的java api。 在做的过程中我发现完全的Redis原生命令可能有120+个，其中有的比较复杂，并且可能应用场景较少。 如 https://github.com/mosn/layotto/issues/530 中提到的，我遇到的常见的数据结构主要有： + string + hash + key + list + set + sorted set + geo 按照"starting simple"的思路，或许可以从这些数据结构的api开始设计。 最后，附上capa中的java redis...

Hi，`RedisCommand`方式看起来很棒~我这里有一些想法，随便聊聊： #### 1. 用户应该不希望面向 [多行文本](https://redis.io/docs/reference/protocol-spec/) 编程，而是面向语义清晰的api进行编程。 这样，还是需要定义很多in-process的api吧（比如我上面提到的capa的那一堆接口定义），最终需要映射到 一百多个grpc接口 或者 RedisCommand 上的。 + 一百多个grpc接口：工作量主要在proto定义上，映射起来会比较方便，或者初期直接让用户调grpc的api也可以。 + RedisCommand：工作量主要在in-process的api的参数转换上（要转换成 RedisCommand的数据格式），以及runtime里面写switch-case来区分命令上。 工作量感觉差不多 #### 2. 考虑和Redis Mesh的混合形式呢 比如一种 [RedisMesh](https://github.com/aeraki-mesh/aeraki/blob/master/docs/zh/redis.md) ，未来可能有这种架构：layotto和x-mesh混用的架构，用户希望redis的功能在redis mesh/layotto之间做选择，或许： + 用户进程 -> grpc流量 ->...

> 使用 RedisCommand 的实际开发量会少一些，对开发者比较友好，但是考虑到命令的参数在接口上的限制会变弱，使用体验上会稍微差些，我考虑的话虽然定义独立的 grpc 接口编写的代码会稍多，但总归是有限的一次性工作，长期来看更加合理，个人更倾向于 grpc 接口 看起来是的，一次性的工作 > 另外我在想，是不是能写个简单一个脚本，通过您之前在 capa 定义的 java 接口，初始化一波 grpc 接口定义，应该能减少一些工作量 哈哈，也可以试试idea的列编辑模式

Hi, 有没有 `app->(grpc)->layotto sidecar->(redis)->redis server` 和 `app->(redis)->redis server`的性能对比呢

What I'm curious about is how the user's program gets custom fields such as `partitionkey`. Is it possible to move custom configuration(metadata fields) from the code into the `config component`...

I know you are busy with the `loom` project recently, do you consider adding this feature to the `loom` project?

You mentioned in #2625 to keep the API surface area relatively small, that's good. But in actual systems, people hope to use VAVR to achieve higher-level functions(Using the basic API...