servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bismy" <bi...@qq.com>
Subject 回复:about protobuf codec switch from protoStuff to jackson
Date Fri, 29 Jun 2018 02:53:31 GMT
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"<zzzwjm@gmail.com>;
发送时间: 2018年6月28日(星期四) 下午4:46
收件人: "dev"<dev@servicecomb.apache.org>;

主题: 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?
Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message