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...... >>> >>
