You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicecomb.apache.org by wjm wjm <zz...@gmail.com> on 2018/09/15 01:36:42 UTC

[Discuss] new problem of protobuf

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

Re: [Discuss] new problem of protobuf

Posted by wjm wjm <zz...@gmail.com>.
https://issues.apache.org/jira/browse/SCB-676

will add more information in it.

Willem Jiang <wi...@gmail.com> 于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 <zz...@gmail.com> wrote:
> >
> > +1
> >
> > Willem Jiang <wi...@gmail.com> 于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 <bi...@qq.com> 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"<zz...@gmail.com>;
> > > > 发送时间: 2018年9月15日(星期六) 上午10:44
> > > > 收件人: "dev"<de...@servicecomb.apache.org>;
> > > >
> > > > 主题: 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 <zz...@gmail.com> 于2018年9月15日周六 上午10:30写道:
> > > >
> > > > > problem is: protobuf not allow to define List<LIst>/ List<Map>
> > > > >
> > > > > wjm wjm <zz...@gmail.com> 于2018年9月15日周六 上午10:27写道:
> > > > >
> > > > >> it's not protoStuff problem.
> > > > >> protoStuff not suport serialize/deserialize without class
> > > > >>
> > > > >> Willem Jiang <wi...@gmail.com> 于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 <zz...@gmail.com>
> 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......
> > > > >>>
> > > > >>
> > >
>

Re: [Discuss] new problem of protobuf

Posted by Willem Jiang <wi...@gmail.com>.
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 <zz...@gmail.com> wrote:
>
> +1
>
> Willem Jiang <wi...@gmail.com> 于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 <bi...@qq.com> 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"<zz...@gmail.com>;
> > > 发送时间: 2018年9月15日(星期六) 上午10:44
> > > 收件人: "dev"<de...@servicecomb.apache.org>;
> > >
> > > 主题: 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 <zz...@gmail.com> 于2018年9月15日周六 上午10:30写道:
> > >
> > > > problem is: protobuf not allow to define List<LIst>/ List<Map>
> > > >
> > > > wjm wjm <zz...@gmail.com> 于2018年9月15日周六 上午10:27写道:
> > > >
> > > >> it's not protoStuff problem.
> > > >> protoStuff not suport serialize/deserialize without class
> > > >>
> > > >> Willem Jiang <wi...@gmail.com> 于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 <zz...@gmail.com> 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......
> > > >>>
> > > >>
> >

Re: [Discuss] new problem of protobuf

Posted by wjm wjm <zz...@gmail.com>.
+1

Willem Jiang <wi...@gmail.com> 于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 <bi...@qq.com> 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"<zz...@gmail.com>;
> > 发送时间: 2018年9月15日(星期六) 上午10:44
> > 收件人: "dev"<de...@servicecomb.apache.org>;
> >
> > 主题: 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 <zz...@gmail.com> 于2018年9月15日周六 上午10:30写道:
> >
> > > problem is: protobuf not allow to define List<LIst>/ List<Map>
> > >
> > > wjm wjm <zz...@gmail.com> 于2018年9月15日周六 上午10:27写道:
> > >
> > >> it's not protoStuff problem.
> > >> protoStuff not suport serialize/deserialize without class
> > >>
> > >> Willem Jiang <wi...@gmail.com> 于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 <zz...@gmail.com> 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......
> > >>>
> > >>
>

Re: [Discuss] new problem of protobuf

Posted by Willem Jiang <wi...@gmail.com>.
+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 <bi...@qq.com> 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"<zz...@gmail.com>;
> 发送时间: 2018年9月15日(星期六) 上午10:44
> 收件人: "dev"<de...@servicecomb.apache.org>;
>
> 主题: 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 <zz...@gmail.com> 于2018年9月15日周六 上午10:30写道:
>
> > problem is: protobuf not allow to define List<LIst>/ List<Map>
> >
> > wjm wjm <zz...@gmail.com> 于2018年9月15日周六 上午10:27写道:
> >
> >> it's not protoStuff problem.
> >> protoStuff not suport serialize/deserialize without class
> >>
> >> Willem Jiang <wi...@gmail.com> 于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 <zz...@gmail.com> 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......
> >>>
> >>

回复: [Discuss] new problem of protobuf

Posted by bismy <bi...@qq.com>.
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"<zz...@gmail.com>;
发送时间: 2018年9月15日(星期六) 上午10:44
收件人: "dev"<de...@servicecomb.apache.org>;

主题: 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 <zz...@gmail.com> 于2018年9月15日周六 上午10:30写道:

> problem is: protobuf not allow to define List<LIst>/ List<Map>
>
> wjm wjm <zz...@gmail.com> 于2018年9月15日周六 上午10:27写道:
>
>> it's not protoStuff problem.
>> protoStuff not suport serialize/deserialize without class
>>
>> Willem Jiang <wi...@gmail.com> 于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 <zz...@gmail.com> 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......
>>>
>>

Re: [Discuss] new problem of protobuf

Posted by wjm wjm <zz...@gmail.com>.
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 <zz...@gmail.com> 于2018年9月15日周六 上午10:30写道:

> problem is: protobuf not allow to define List<LIst>/ List<Map>
>
> wjm wjm <zz...@gmail.com> 于2018年9月15日周六 上午10:27写道:
>
>> it's not protoStuff problem.
>> protoStuff not suport serialize/deserialize without class
>>
>> Willem Jiang <wi...@gmail.com> 于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 <zz...@gmail.com> 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......
>>>
>>

Re: [Discuss] new problem of protobuf

Posted by wjm wjm <zz...@gmail.com>.
problem is: protobuf not allow to define List<LIst>/ List<Map>

wjm wjm <zz...@gmail.com> 于2018年9月15日周六 上午10:27写道:

> it's not protoStuff problem.
> protoStuff not suport serialize/deserialize without class
>
> Willem Jiang <wi...@gmail.com> 于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 <zz...@gmail.com> 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......
>>
>

Re: [Discuss] new problem of protobuf

Posted by wjm wjm <zz...@gmail.com>.
it's not protoStuff problem.
protoStuff not suport serialize/deserialize without class

Willem Jiang <wi...@gmail.com> 于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 <zz...@gmail.com> 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......
>

Re: [Discuss] new problem of protobuf

Posted by Willem Jiang <wi...@gmail.com>.
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 <zz...@gmail.com> 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......