Oliver Zou

superagent

same as pull requset #63

应强调一致性，虽然是跨语言的，但是文档却是各个语言分开的，反而模糊了跨语言一致性的优点（如果跨语言不一致是很糟糕的结果）。文档应只有一份，强调一致的部分，不一致的部分不必要强调，语言只在示例中体现不同。文档一份只是形式要求，实质希望让使用者在概念上理解不同语言有一致的实现，不会有意外，从而放心使用。如果现有各个语言实现有不一致的，可以通过同一份文档来规范一致性，达不到基本一致性要求的语言可暂时放弃。另，我现在用protobuf+hprose在项目中解决问题，使用protobuf是因为有可持续的跨语言规范维护要求，也就是说项目需要idl来维护各个语言一致性，因为维护起来方便，idl有其实际意义，当然这和hprose无冲突，但却可以说明无需idl不能说是个太大的优点。grpc能支持的语言已经涵盖主流，golang和javacript已经支持的很完善了，hprose如果能在工程角度给开发带来更多帮助，使用更方便简洁，才能具备更大优势。

几个建议： 1. 感觉3.0走偏了。我的建议是在2.0的基础上改善现有使用问题。做到解决核心用户需求。实现的美观问题，以及插件问题只是解决开发问题而不是rpc基本需求问题。 2. hprose 3.0如果不能尽快实现大部分语言，而2.0的客户端没法完全调用3.0的服务，建议3.0另立山头和2.0严格区分开来，2.0作为LTS长期存在和维护。 3. hprose的一个优势，不是效率，而是在客户端接口声明、定义再完成后，使用起来的自然性，便利性，和使用一个本地函数一样。grpc的缺点就是不自然。这个优势目前我只看到ZeroC Ice另有做到。 4. 然而，客户端必须再声明和服务器一样的接口，这个问题是要命的，我想可能是假设了客户端和服务器的使用者是同样的团队。先不论大量接口的情况，rpc接口暴露出去，未必是给自己人用，即使是同一个公司内部。举个栗子，应用场景需要使用各种语言客户端，居然每种语言的客户端的rpc接口定义都得在客户端手工定义一遍，先不论每种语言的定义差异，就算定义出来了，要改得麻烦死了。所以，在没有idl生成一致接口定义的情况下，hprose难以使用。建议，以protobuf idl文件为中间类型和接口定义文件，实现工具，把各个语言下的hprose客户端所需引用的rpc接口本地定义文件生成出来，便于客户端直接使用。同时也能部分解决grpc的迁移问题。 5. 推送方面，其实未必hprose自己实现，可以使用同样是支持多语言的nats等消息推送系统，当然，如果hprose有时间实现的不错也是可以的，现实是没太多时间。 6. hprose的远期目标，应该是忽略网络存在感的rpc调用解决方案。不在网络问题中纠缠。 随笔，仅供参考。

另注：pb生成的各个语言类型和接口定义文件，在hprose中并不能直接适用，pb并不是简单生成pojo对象，命名也各有差异，需要做大量适配工作。

谢谢回复。 关于服务接口，我也了解使用hprose的确是不需要定义服务接口的。”客户端必须再声明和服务器一样的接口“确实不准确，不能用’必须‘。这个问题应该这么来说： 1.客户端需要获取接口信息。客户端虽然可以不用定义接口，但需要获取接口信息。客户端和服务端开发协作中（不一定是一个团队或者公司，客户端甚至是客户），如果没有接口定义，客户端是如何知道服务端提供了哪些服务？如何了解具体api形态如何？即使是弱类型语言，依然也要知道有哪些什么样的服务吧。通过文档？文档不具备强制性，开发过程中难以保证客户端和服务端的一致性。（这种”一致性“，仅要求连接点和输入输出类型信息，未必要求调用方式的一致性，异步或者同步调用方式并不影响一致性），而idl本身就是语言无关的精确文档。 2.接口便利性是重要的，虽然不用定义接口，但如果使用不方便，不用定义接口就不能成为一个优势。而hprose的一个重要优势是接口使用便利。对于强类型语言，如果要自然方便的使用rpc接口，就需要在客户端定义接口。一般情况下没什么，但在客户端不是服务器团队甚至是客户的团队的情况下，接口易用性是要满足的，总不能让客户全调用invoke，从用户角度，invoke接口并不便利。总之，在接口多，语言多且持续维护的情况下，客户端为了便利性从而需要定义接口，但这样存在较大的不便性。 另外，以IDL来定义接口，未必就是强行统一客户端和服务端的接口的方方面面，idl的客户端代码生成完全可以存在多个版本的调用形式，定义相同的结构对象在不同语言的接口中，可以使用map或者object或者struct对象，依语言情况而用，hprose的io可以保证解析成功。所以idl编译生成的代码，只需要客户端能够访问到服务端的这个函数，服务端能获取参数即可，两端的调用参数形式上不要求一定完全一样，但接口信息类型信息总是要有的，这是idl编译工具的实现问题。必要的话在idl编译参数明确指定即可。 一家之言，仅供参考。

客户端 SetMaxPoolSize，默认是2，可以设置大一点。每个订阅占用一个连接，注意订阅的数量不能大于poolsize。但客户端多的情况，服务器连接过多，建议只订阅一个，用字段区分。

有什么办法从客户端向服务器端不通过rpc api的参数传递一个data？就像http中post可以携带一个header变量Authorization实现认证。

查了源码，context和userdata都和想象的不一样，文档也没有足够清楚。简单扩展一下可以解决问题。解决rpc中的auth2认证问题。