I am trying to use proto2 on client-side and proto3 on server-side. My
schema files use extensions, and I am assuming this is still true so I
cannot do it?
Can anybody confirm?
On Thursday, April 28, 2016 at 6:18:12 PM UTC-4, Feng Xiao wrote:
>
>
>
> On Tue, Apr 26, 2016 at 7:04 PM, Bo Gao >
>
The handling of unknown fields is precisely where the difference lies and
sticking to proto2 is indeed the plan. However, because you have many
clients forced to stick with proto2, you inevitably bifurcate the users,
and implementations are now forced to support two standards. Proto3 was
designed s
> On May 18, 2016, at 10:01 PM, Jeremy Ong wrote:
>
> Why does adding JSON require dropping unknown fields? So long as fields are
> keyed to field number, I don't see why the JSON encoding requires special
> treatment with respect to the binary one.
JSON fields aren’t keyed to field number.
Why does adding JSON require dropping unknown fields? So long as fields are
keyed to field number, I don't see why the JSON encoding requires special
treatment with respect to the binary one.
I can understand how transitioning between major versions may require
breaks in compatibility. However, pr
After studying proto3 pretty carefully, I’ve come around quite a bit on these
changes:
I believe adding JSON requires dropping unknown fields. You simply cannot
preserve unknown fields and properly support multiple encodings.
I’m less sure about replacing extension support with Any. Extension
Big fan of 4, 5, 6, and 7. Huge un-fan of 2, and 3. I am mixed on 1 because
I love the removal of required fields, hate the removal of field presence.
All the changes I dislike are significant losses in functionality and break
compatibility with existing users of proto2 and I'd be interested to
und
On Wed, May 18, 2016 at 9:27 AM, Artem Kazakov wrote:
> +1
> Yes, a checklist would be extremely helpful.
>
>
> On Friday, April 29, 2016 at 5:04:56 PM UTC-4, Kostiantyn Shchepanovskyi
> wrote:
>>
>> It would be nice to have a migration guide (checklist) somewhere, like:
>>
>> 1. All fields shoul
Protobuf schema evolution rules:
https://developers.google.com/protocol-buffers/docs/proto#updating
On Wednesday, May 18, 2016 at 11:09:15 AM UTC-7, Artem Kazakov wrote:
>
> +1
> Yes, a checklist would be extremely helpful.
>
> On Friday, April 29, 2016 at 5:04:56 PM UTC-4, Kostiantyn Shchepanov
+1
Yes, a checklist would be extremely helpful.
On Friday, April 29, 2016 at 5:04:56 PM UTC-4, Kostiantyn Shchepanovskyi
wrote:
>
> It would be nice to have a migration guide (checklist) somewhere, like:
>
> 1. All fields should be optional.
> 2. Do not use custom defailt values.
> 3. All enums
It would be nice to have a migration guide (checklist) somewhere, like:
1. All fields should be optional.
2. Do not use custom defailt values.
3. All enums should have first element with tag = 0.
4. Do not use extension for anything except custom options.
Something else?
On Friday, April 29, 201
On Tue, Apr 26, 2016 at 7:04 PM, Bo Gao wrote:
> suppose server side is updating into protobuf3, but client side still use
> protobuf2, can then communicate will?
>
Yes, as long as you only use proto3 features, they are wire compatible.
> --
> You received this message because you are subscribe
suppose server side is updating into protobuf3, but client side still use
protobuf2, can then communicate will?
--
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
12 matches
Mail list logo
