Kevin_T
Kevin_T
> @kevinten10 问下，改 layotto配置的时候，用 configmap挂载新的config.json、重启，能满足需求对吧？ 满足的。以及，configmap有热更新吧，不知道layotto能监听到config.json的变更吗
> @kevinten10 hi 我确认下，上次说 Poc 跑通了 是指哪些能力跑通啦？ #### 部署通了： pod内有4个container： 1. init (aws appmesh) 2. bussiness 3. envoy (aws appmesh) 4. layotto runtime 在这种情况下，bussiness container可以正常运行并提供服务 > 我想了下，感觉需要跑下 rpc 的 poc，即...
我看到一个有趣的项目，或许可以参考一下： quarkus和dapr sdk的集成：https://github.com/quarkiverse/quarkus-dapr/issues/5
> configuration API 订阅的功能在参考 pubsub API 订阅 Hi，我有个疑问点。为什么不把pubsub的订阅放入runtime API定义中呢。而是放到appcallback API中。 就像configuration的订阅API： ```proto rpc SubscribeConfiguration(stream SubscribeConfigurationRequest) returns (stream SubscribeConfigurationResponse) {} ``` 完全可以在runtime API去定义pubsub的subscribeEvent API啊。
like this: https://github.com/capa-cloud/cloud-runtimes-jvm/blob/master/cloud-runtimes-api/src/main/java/group/rxcloud/cloudruntimes/domain/core/PubSubRuntimes.java 在SDK模型中，似乎无法很好的定义appcallback API，所以我们采用的是类似configuration的subscribe方式。 即`Server streaming`或`Bidirectional streaming`风格的runtime API。
> @kevinten10 看起来我们可以试试把layotto的client直接注入到spring-boot中? 现在的做法是单功能注解 我觉得可以，用户可以直接从spring ioc中获取到一个client(带有默认参数)，直接使用这个client即可。
I understand it like defining an adaptation layer to decouple business logic from wasm implementation (proxy-wasm). What might be done is: 1. Define a simple interface, which is abstract 2....
如果是GET请求，请求参数会放在path里面吗
从长远来看，如果两种都支持呢。 从使用方的角度，如果要写一些通用逻辑，可能倾向于使用`handleRequest`方式；如果要针对 RPC/MQ 逻辑，可能倾向于使用`handleHttpRequest`方式。 --- 假如，如果假如未来要两种都支持。 是不是一开始往 `handleRequest` 方向做会好一些，将来可以拆成各类具体协议的函数。 如果一开始往`handleHttpRequest`这种绑定的方向做，可能会加很多case by case的特殊逻辑，以致于未来无法合并。