will match that proto
version encoding. Isn't it the case?
Thanks,
Yoav.
On Tuesday, March 29, 2016 at 5:06:46 PM UTC-7, Feng Xiao wrote:
>
>
>
> On Mon, Mar 28, 2016 at 10:53 PM, Yoav H > wrote:
>
>> They say on their website: "When evaluating new features,
ding a new message). The Java API has something rather
> similar... hasField() I think?
>
> On Sat, Mar 26, 2016 at 4:00 PM, Yoav H > wrote:
> > Thanks all,
> >
> > Do you know where I can find the proto2 encoding guide?
> > The proto site has only the prot
ggestions I'm only a 3rd party implementer but
> my understanding is that the design process of protocol buffers and its
> goals are internal to Google and they usually publish new versions of their
> code implementing new features before you can read about them in the
> documents.
Any comment on this?
Will you consider this for proto3?
On Wednesday, March 23, 2016 at 11:50:36 AM UTC-7, Yoav H wrote:
>
> Hi,
>
> I have a suggestion fr improving the protobuf encoding.
> Is proto3 final?
>
> I like the simplicity of the encoding of protobuf.
> But
Thanks all,
Do you know where I can find the proto2 encoding guide?
The proto site has only the proto3 encoding described.
On Saturday, March 26, 2016 at 12:21:39 PM UTC-7, Tim Kientzle wrote:
>
>
> > On Mar 26, 2016, at 11:43 AM, Yoav H >
> wrote:
> >
> > Hi,
&
Hi,
I wanted ask regarding the decision to populate fields with default values,
even if they do not appear in the encoded message.
If I want to send a "patch" message, where I want to update just the
provided fields, how can I do that with protobuf (without adding IsXXXSet
for every field)?
Wh
Hi,
I have a suggestion fr improving the protobuf encoding.
Is proto3 final?
I like the simplicity of the encoding of protobuf.
But I think it has one issue with serialization, using streams.
The problem is with length delimited fields and the fact that they require
knowing the length ahead of t
