Yes, in Cap'n Proto, fields take space regardless of whether or not they've
been "set". This is because fields are identified by their offset from the
start of the struct, not by tags, which is what makes efficient zero-copy
random access possible. Unset fields are always encoded as zeros on the
wire (even if they have non-zero defaults).
-Kenton
On Wed, Nov 20, 2019 at 1:06 PM Vitali Lovich <vlov...@gmail.com> wrote:
> Thanks Ian and Kenton. That's very helpful.
>
> For the unused wire space, is that still true for AnyPointer fields that
> aren't set?
>
> On Wed, Nov 20, 2019 at 1:02 PM Kenton Varda <ken...@cloudflare.com>
> wrote:
>
>> Hi Vitali,
>>
>> In general, the way we "remove" fields is by renaming them to add the
>> prefix "obsolete". As Ian points out, you can also change any pointer type
>> to AnyPointer, and enum types to UInt16, to allow you to delete the
>> referenced type definition.
>>
>> This does leave unused space in your messages on the wire. That space
>> will be zero'd, so it compresses well, at least. You can also potentially
>> reuse the space for a new field *if* you are confident that all users of
>> the old field are gone. This of course tends to be easy to guarantee for
>> internal protocols and impossible for public ones.
>>
>> -Kenton
>>
>> On Wed, Nov 20, 2019 at 11:47 AM Vitali Lovich <vlov...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> What's the equivalent process to removing a protobuf field in capnproto?
>>> In protobuf you could just delete it but for capnproto it looks like not
>>> only does it have to stick around so do it's type definition?
>>>
>>> So something like:
>>>
>>> Struct Foo {
>>> deprecatedField @0 :Bar
>>> }
>>>
>>> Means I have to keep the definition for Bar around. Is there a process
>>> through which I can eventually get rid of Bar? Any recommendations on how
>>> to demarcate the deprecated field as "deleted"?
>>>
>>> The best I've come up with is to just delete the contents of Bar and
>>> change its name to indicate it's no longer used but wondering if there's a
>>> safer way (I'm guessing changing the field to Void won't work)
>>>
>>> Thanks,
>>> Vitali
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Cap'n Proto" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to capnproto+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/capnproto/CAF8PYMhhqv6groL50Kbn_%3DRPrg4OJuKrxyxpO2qTiYz7onJi4w%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/capnproto/CAF8PYMhhqv6groL50Kbn_%3DRPrg4OJuKrxyxpO2qTiYz7onJi4w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/CAJouXQmCVe5nbeGoHhKPCR%3DqXb392AwN3%3D%3DhWX6XpS%3DmUMULXA%40mail.gmail.com.
