Marco

@byene0923 yes! At the first version, we just need to finish the basic functions which i think maybe not easy, such as `connection manager`, `decode/encode`, `serialization/deserialization`, when you finish the...

Yes! I also prefer to keep using `proxy-wasm` if it can reduce our workload, the only thing I worried about is it's a little more complicated.

@leemos-xx 这个提案想要做的基本就是你说的这些。 - 关于你说的Http跟Event，我们可以归类为函数的触发方式，也就是function trigger，一般来说可以有HTTP、RPC、消息等类型，这块我建议是从支持HTTP开始做，如果这种触发方式成熟了，那我们后面可以考虑增加更多的触发方式。 - 这个API你是指的函数暴露给用户用于开发的API吗？一般来说我们认为函数的逻辑比较简单，也就是说比如只需要实现一个`handle`方法即可。但如果暴露一些提升用户开发体验的API那也是可以的，比如提供init跟destroy两个方法，一个用于函数加载完成时回调，一个用于函数销毁前回调，或许可以让用户执行一些初始化或销毁的操作

@leemos-xx 大体上跟我思路差不多，关于`handleHttpRequest` 这里抛出一个点讨论一下，就是函数是否要跟协议绑定。 1. 如果绑定的话，按照上面的提案搞问题不大。不过这种方案下用户开发一个函数就是面向协议了，也就是处理HTTP请求要写一个函数，处理MQ请求要写另一个函数。 2. 如果函数跟协议解耦，比如用户实现的是`handleRequest`，而访问函数的方式独立成触发器，比如可以是定时任务触发，可以是消息触发，也可以是请求触发（HTTP, gRPC等）。这用方式下，关于请求类型可以放到你提的`context`中，比如 | 字段 | 说明 | | ---- | ---- | | requestId | 本次请求的唯一id，当出现问题时方便排查。 | | logger | 日志对象，用于格式化输出日志，提供不同的日志级别。 | | triggerType（requestType）...

@kevinten10 @leemos-xx 那比如现在阶段把函数实现跟触发器分开，比如函数实现`handleRequest`接口，入参是一个`byte[]`类型，然后触发器先只支持HTTP，这中间有一层转换逻辑，比如把上面提到的fc.HttpBody取出来作为`byte[]`类型传入？ 总体来说我还是倾向于小步快跑，不用一次性搞的太复杂，一点点来好一点。 另外今天跟 @Mossaka 聊了一下，他推荐了一个 https://github.com/bytecodealliance/wit-bindgen 我们在Demo改造上可以参考一下这个项目看能不能用上，可以减少我们写转换层的工作量 我这周末也研究一下

另外关于`zkCreateZNode.sh` 脚本里的内容本质上是由于Layotto实现有问题导致的，详细信息可用参考 #747 感兴趣也可以fix一下🤝

@alexcrichton Thanks for your reply! Is there currently a planned time to complete the first step? maybe on November or December ? hhhh I think that supporting wasm's resource restriction...

OK, although i am new to rust, i will have a try😊

@alilestera 可以参考下之前的设计：https://github.com/mosn/layotto/issues/716 看是否能兼容

Reference issue: https://github.com/mosn/layotto/issues/476