wenxuwan
3这个需求会有用户有需求吗？感觉proxyless宣传的是很多，但实际貌似没什么太大需求，有有需求的大佬们?
please add ut case to fix the ut coverage
> hi, why do this "call InvokeAsync function"? I want to reuse the underlying client to get some key-value values from rocketmq, and then do some business logic。 In java,...
> Hi，此功能是否可以兼容以下场景呢： > > 例如部署layotto + envoy，流量先经过layotto做处理，layotto再将流量直接转发给envoy。 > > * 流量不经过mosn。可能是 `app -> (http/grpc) -> layotto -> (http) -> envoy -> target service > * layotto->envoy走L7的http转发，而不是L4的ip转发。那是不是要加一个rpc_target_url 当前的layotto是可以通过下面的配置将invoke转成http协议的。所以说理论上协议应该使用当前的protocol字段来配置，只用一个rpc_target_address字段来指定目标地址就可以了。 
> 另，有这样一种场景： > > IM api在私有云内部可以直接访问，但在公有云上无法直接访问，可能要通过转发/验证/代理等方式才能访问。 > > 这样哪怕我已有多语言的sdk，还是要为每种语言的sdk重新开发一套转发/代理的功能。 这时候我希望把这个逻辑放在sidecar中，这样只需要开发一次即可，对api也没有变动。 > > 综上，我个人觉得值得将IM api下沉到sidecar中，主要解决了多语言sdk的问题和后续自定义功能复用的问题。 > > 如果社区有成熟api，那复用也完全可以呢。 目前看来为了解决的问题： 1.解决多语言问题。 2.后续自定义功能复用（有可能会复用到） 那这个问题和dapr的outbinding是完全契合的。 可以参考一下：https://github.com/dapr/dapr/issues/3722
> Hi，notify api确实在特征上，和dapr 的binding是契合的。 > > 因为我个人比较大量的使用过notify api，所以我认为这套api具有实际意义，那对于这类api，我感觉从binding中拆出来会比较好呢： > > bingding是一个较低级别的抽象，我们可以把任何东西都塞在里面。在初期，可能尽快的对接更多系统，先把东西放进去。但随着multi-runtime的发展，当我们发现一些领域的api具有更大使用价值时，我们可能要考虑将它们独立定义。 > > 就sidecar中component的实现而言，我认为在layotto中基于binding写一个notify的组件，和单独定义一个notify的组件，可能没有什么大的不同。 > > 但在用户层（或者说用户使用sdk时），这将有很大的不同：我们不可能要求用户使用原始的binding api，假如用户需要参照文档，自己往binding api中传那么多的参数/结构，这不够便利。那么就需要在这之上，为用户构建便捷易用的多语言的sdk api。 > > > 就这一点，我怀疑dapr binding api的实际用户有多少，上云应该是增效的过程，如果开发人员陷入了参考文档写binding api的困境，那为什么不使用开源已有的sdk呢，或者又要在这之上封装自己的sdk工具库了。 > > 这就引入了以上问题，当我们在多语言sdk中定义这样的方法时，并将它们映射到binding...
可以试一下layotto进程级别部署，把layotto和业务容器做到一个container中，而不是作为sidecar存在。如果内存和cpu有负担，layotto这边也可以尝试阉割一部分用不到的能力。以此减少性能的影响。
may be ut is better, ci complexity is too high。Can ask users to post their own test reports。
> > may be ut is better > > UT can't find out bugs. But integration tests can. Examples are #669 and #574 > > > ci complexity is too...
> > Our code review process is slow, and hard. I want to make PR review faster. > > From my perspective, the current issue `help maintainers review PR faster`...