Re: Investigation of Existing Encoding Formats

Tested encoding a simple request, contains a few int fields and a couple
small byte arrays:

   - Custom encoding: 73 bytes
   - Protobuf: 86 bytes
   - CBOR: 89 bytes

A more complex response object, this contains a large int array and a large
byte array:

   - Custom: 9041 bytes
   - Protobuf: 9074 bytes
   - CBOR: 9086 bytes

From these two examples it looks like all three encodings are pretty close
in terms of size.

On Thu, Jan 28, 2021 at 12:33 PM Garret Rieger <grieger@google.com> wrote:

> Good idea, I'll generate protobuf, custom, and CBOR encodings for a few
> sample request/responses so we can get a more concrete picture on the
> encoding overhead for each format.
>
> On Wed, Jan 27, 2021 at 7:06 PM Chris Lilley <chris@w3.org> wrote:
>
>>
>> On 2021-01-27 23:09, Garret Rieger wrote:
>>
>> CBOR (Concise Binary Object Representation)
>>
>> CBOR - Wikipedia <https://en.wikipedia.org/wiki/CBOR>, rfc8949
>> <https://tools.ietf.org/html/rfc8949>
>>
>> I agree that CBOR looks like a good candidate; standardized, multiple
>> implementations.
>>
>> It would perhaps be wise to encode some sample transactions in CBOR and
>> in the originally proposed custom encoding, just to check that the overall
>> sizes are comparable. But assuming that checks out, this does look like the
>> best choice from the options you listed.
>>
>> Ah, I notice that this is one of the more modern RFCs which is also
>> available as-authored in html, as well as the traditional IETF "looks like
>> a lineprinter" format.
>>
>> Compare
>>
>>   https://tools.ietf.org/html/rfc8949
>>
>> and
>>
>>   https://www.rfc-editor.org/rfc/rfc8949.html
>>
>> Oh cool, specref already has this
>>
>>   https://api.specref.org/bibrefs?refs=rfc8949
>>
>> so a reference in the bikeshed like [[rfc8949]] will work correctly.
>>
>> --
>> Chris Lilley
>> @svgeesus
>> Technical Director @ W3C
>> W3C Strategy Team, Core Web Design
>> W3C Architecture & Technology Team, Core Web & Media
>>
>>