https://issues.apache.org/jira/browse/SCB-676
will add more information in it. Willem Jiang <[email protected]> 于2018年9月18日周二 上午9:27写道： > Hi wjm, > > Could you summarize the solution for this issue? > Add some JIRA link for it, so other people can follow it up with these > information. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Mon, Sep 17, 2018 at 11:45 PM wjm wjm <[email protected]> wrote: > > > > +1 > > > > Willem Jiang <[email protected]> 于2018年9月15日周六 下午2:35写道： > > > > > +1. > > > We could let the user make their own choice by providing the detail > > > information about different protocol can do. > > > > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Sat, Sep 15, 2018 at 2:22 PM bismy <[email protected]> wrote: > > > > > > > > Our goal is to design a transparent programming model for RPC, > JAX-RS & > > > Spring MVC. Users do not need to know about which transport is used, > and > > > can change it freely when deploying. > > > > > > > > > > > > However, with user requirements grows, we have already provided some > > > features can only be used for REST. > > > > > > > > > > > > My suggestion is we need to document explicitly the core programming > > > model that are supported by all transports, and list the specific > features > > > for different transports. > > > > > > > > > > > > Regards your problems, I think we should following protobuffer > > > specifications, and not support this feature. > > > > > > > > > > > > If we can give some warning messages to users is preferred when they > use > > > this feature in highway. > > > > > > > > > > > > ------------------ 原始邮件 ------------------ > > > > 发件人: "zzzwjm"<[email protected]>; > > > > 发送时间: 2018年9月15日(星期六) 上午10:44 > > > > 收件人: "dev"<[email protected]>; > > > > > > > > 主题: Re: [Discuss] new problem of protobuf > > > > > > > > > > > > > > > > seems no way to resolve this > > > > maybe we can only log message that this schema not support highway > and > > > > select rest transport automatically > > > > > > > > wjm wjm <[email protected]> 于2018年9月15日周六 上午10:30写道： > > > > > > > > > problem is: protobuf not allow to define List<LIst>/ List<Map> > > > > > > > > > > wjm wjm <[email protected]> 于2018年9月15日周六 上午10:27写道： > > > > > > > > > >> it's not protoStuff problem. > > > > >> protoStuff not suport serialize/deserialize without class > > > > >> > > > > >> Willem Jiang <[email protected]> 于2018年9月15日周六 上午10:18写道： > > > > >> > > > > >>> Hi Jimin, > > > > >>> The best way is we send a PR for protoStuff to provide the > solution > > > of > > > > >>> listList/listMap, but it may not meet the needs of our release > > > > >>> schedule. > > > > >>> I don't think maintain a fork version of protoStuff is good way > to > > > go. > > > > >>> If we can wrap the protoStuff and extends it ourselves, it may > meet > > > > >>> the needs of our release schedule. > > > > >>> > > > > >>> Willem Jiang > > > > >>> > > > > >>> Twitter: willemjiang > > > > >>> Weibo: 姜宁willem > > > > >>> > > > > >>> On Sat, Sep 15, 2018 at 9:36 AM wjm wjm <[email protected]> > wrote: > > > > >>> > > > > > >>> > class Test { > > > > >>> > public List<List<String>> listList; > > > > >>> > public List<Map<String, String>> listMap; > > > > >>> > } > > > > >>> > > > > > >>> > the field listList/listMap is invalid in protobuf. > > > > >>> > ----------- > > > > >>> > > > > > >>> > currently we process this by protoStuff runtimeSchema, > > > runtimeSchema > > > > >>> > generated from Test class, and runtimeSchema can support the > > > > >>> definition of > > > > >>> > listList/listMap(that's protoStuff rule, not protobuf rule) > > > > >>> > but because there are no classes in Edge service, currently we > must > > > > >>> dynamic > > > > >>> > create new classes for protoStuff, that caused many problems. > > > > >>> > > > > > >>> > as we discussed before, we will not dynamic create new classes, > > > just > > > > >>> > serialize/deserialize by proto file, and proto file not support > > > > >>> > the definition of listList/listMap > > > > >>> > in this time, we must faced the compatible problem. > > > > >>> > what's the best of our choice...... > > > > >>> > > > > >> > > > >
