There may be some background information not given very clearly.
If we are addressing the problem that: 1. Edge service dispatch requests will decode requests and encode to Invocation, this is not flexible and need compile different versions of schema to class. And 2. support more flexible user interfaces like custom headers not included in schema This problems come from support of Highway (which using protobuffer), but using REST(json based), we will not have this problem. Now: consumer side: (pojo/springmvc client) -> Invocation(args) -> Transport(args -> json, rest; args -> protobufer, highway) provideer side: Transport(json -> args, rest; protobuffer -> args, highway) -> Invocation(args) -> (pojo/springmvc/jaxrs) providers, handlers and transports can see schema info too. We want to change to: consumer side: (pojo/springmvc client) -> Invocation(HttpServletRequestExt, headers, body, queries. args for compatible and translate on demand) -> Transport(HttpServletRequestExt, rest; HttpServletRequestExt -> args -> protobufer, highway) provideer side: Transport(HttpServletRequestExt -> HttpServletRequestExt,, rest; protobuffer -> args -> HttpServletRequestExt, highway) -> Invocation(HttpServletRequestExt) -> (pojo/springmvc/jaxrs) if we use protoStuff, for highway should be: protobuffer -> args -> HttpServletRequestExt and jackson: protobuffer -> idl -> HttpServletRequestExt I think we can still use protoStuff to solve the problem. The above understanding may be not quite correct. If I missed something? ------------------ ???????? ------------------ ??????: "wjm wjm"<[email protected]>; ????????: 2018??6??28??(??????) ????4:46 ??????: "dev"<[email protected]>; ????: about protobuf codec switch from protoStuff to jackson protoStuff support all protobuf v3 features and very fast but protoStuff: 1.must based on java class, can not construct from idl, this is not good in edge. 2.can not support customize generic class jackson protobuf plugin is good in other feature, but : only support protobuf v2 features some scenes slower than protoStuff, and others faster, it's not a big problem, we can optimize it in the future if we extend jackson protobuf plugin to support protobuf v3 features we must copy and modify source code, because there is no any plugable design for v3 feature it's "copy and modify", we will have too many problems what your suggestion to resolve the problem??
