Re: [protobuf] pros and cons to upgrade protobuf v3

2017-07-14 Thread hce h 

Thanks Josh, we don't use default values, we don't use extensions and we 
don't use accessor methods. All our messages (C++) are using very simple 
native fields and embedded without messages or messages imported from other 
packages. You comments encouraged me even more to upgrade the v3.

Correct me if I am wrong, but I think in v3, if an error message returns 
without filling all fields, the libprotobuf.so will not throw an exception, 
is that correct?

Thank you.

Kind regards,

- j

On Friday, July 14, 2017 at 11:45:18 PM UTC+10, Josh Humphries wrote:
>
> You can use the latest version but still use a corpus files 
> syntax="proto2" files.
>
> Marking required fields as optional is not the only difference (and, in 
> proto2, that is not a particularly safe operation -- you must be certain 
> you've updated *all* readers of those messages with the new definition 
> *before* any writers actually choose to omit those fields).
>
> If you are using default values or extensions, your migration to proto3 
> syntax will be trickier as neither is supported. Also, proto3 doesn't 
> provide accessor methods to detect whether a field is present or not (it is 
> implicitly absent if it has the "zero value" for its type).
>
> Luckily, you can start using the latest protoc and then slowly migrate. 
> The proto compiler does allow a mix of proto2 and proto3 syntax files -- 
> proto3 files can import proto2 files (though I can't recall if the other 
> direction is allowed -- I think it is though, to support custom options 
> that might reference messages defined in proto3). One path for migration is 
> to start using proto3 for all new files. This gives you optionality as far 
> as how and when to convert the rest.
>
> If you don't use default values or extensions, converting a proto2 syntax 
> file to proto3 is quite simple. But, depending on the language you use, it 
> will impact application code that interacts with the generated code. 
> (Proto3 files do not generate pointers in the structs for scalar fields, 
> for example.) Also note that custom options *are* still supported, but 
> since they rely on extensions they must be defined in a file with proto2 
> syntax.
>
> 
> *Josh Humphries*
> jh...@bluegosling.com 
>
> On Fri, Jul 14, 2017 at 7:33 AM, hce h  
> wrote:
>
>> Hi,
>>
>> I had a debate with my colleagues regarding to upgrade protobuf v3 
>> because I'd like to use MessageToJsonString and JsonStringToMessage for GUI 
>> development of web application and mobile app, but my colleagues are not 
>> convinced, they argued GO can do it very easily and they are worrying about 
>> to break the systems down as our protobuf v2 codes are used crossing many 
>> systems. I always think it is logical to use the latest version of the 
>> software which should fix bugs and add more features, in addition to that, 
>> I don't like v2 required field and many of our codes have problems when the 
>> process returns an error message before reaching the destination, the error 
>> message was not able to fill in all required fields caused libprotobufbuf 
>> broken the system daemon, I have recently changed many required fields to 
>> optional, I thought protobuf v3 should be more stable than the v2, but I am 
>> also new to protobuf v3, appreciate your comments.
>>
>> Thank you.
>>
>> Kind regards,
>>
>> -j
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Protocol Buffers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to protobuf+u...@googlegroups.com .
>> To post to this group, send email to prot...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] pros and cons to upgrade protobuf v3

2017-07-14 Thread Josh Humphries 
You can use the latest version but still use a corpus files syntax="proto2"
files.

Marking required fields as optional is not the only difference (and, in
proto2, that is not a particularly safe operation -- you must be certain
you've updated *all* readers of those messages with the new definition
*before* any writers actually choose to omit those fields).

If you are using default values or extensions, your migration to proto3
syntax will be trickier as neither is supported. Also, proto3 doesn't
provide accessor methods to detect whether a field is present or not (it is
implicitly absent if it has the "zero value" for its type).

Luckily, you can start using the latest protoc and then slowly migrate. The
proto compiler does allow a mix of proto2 and proto3 syntax files -- proto3
files can import proto2 files (though I can't recall if the other direction
is allowed -- I think it is though, to support custom options that might
reference messages defined in proto3). One path for migration is to start
using proto3 for all new files. This gives you optionality as far as how
and when to convert the rest.

If you don't use default values or extensions, converting a proto2 syntax
file to proto3 is quite simple. But, depending on the language you use, it
will impact application code that interacts with the generated code.
(Proto3 files do not generate pointers in the structs for scalar fields,
for example.) Also note that custom options *are* still supported, but
since they rely on extensions they must be defined in a file with proto2
syntax.


*Josh Humphries*
jh...@bluegosling.com

On Fri, Jul 14, 2017 at 7:33 AM, hce h  wrote:

> Hi,
>
> I had a debate with my colleagues regarding to upgrade protobuf v3 because
> I'd like to use MessageToJsonString and JsonStringToMessage for GUI
> development of web application and mobile app, but my colleagues are not
> convinced, they argued GO can do it very easily and they are worrying about
> to break the systems down as our protobuf v2 codes are used crossing many
> systems. I always think it is logical to use the latest version of the
> software which should fix bugs and add more features, in addition to that,
> I don't like v2 required field and many of our codes have problems when the
> process returns an error message before reaching the destination, the error
> message was not able to fill in all required fields caused libprotobufbuf
> broken the system daemon, I have recently changed many required fields to
> optional, I thought protobuf v3 should be more stable than the v2, but I am
> also new to protobuf v3, appreciate your comments.
>
> Thank you.
>
> Kind regards,
>
> -j
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] pros and cons to upgrade protobuf v3

2017-07-14 Thread hce h 
Hi,

I had a debate with my colleagues regarding to upgrade protobuf v3 because 
I'd like to use MessageToJsonString and JsonStringToMessage for GUI 
development of web application and mobile app, but my colleagues are not 
convinced, they argued GO can do it very easily and they are worrying about 
to break the systems down as our protobuf v2 codes are used crossing many 
systems. I always think it is logical to use the latest version of the 
software which should fix bugs and add more features, in addition to that, 
I don't like v2 required field and many of our codes have problems when the 
process returns an error message before reaching the destination, the error 
message was not able to fill in all required fields caused libprotobufbuf 
broken the system daemon, I have recently changed many required fields to 
optional, I thought protobuf v3 should be more stable than the v2, but I am 
also new to protobuf v3, appreciate your comments.

Thank you.

Kind regards,

-j

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.