You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
through various issues, seems proto3 is the preferred binary format for the span v2 model. We have some decisions to make, mostly around parity with ids and ips.
For example, we can choose to encode the hex ids as raw bytes (half the size of them)
We can also choose to encode IP addresses literals as raw bytes (sliding scale for ipv6; always smaller for ipv4)
Main thing is that if we do choose a binary encoding for proto3 ids and ips, there's a chance users will encode IDs incorrectly (ex encode IDs as uppercase hex, or '0x' prefixed or worse base64). There's a chance folks will handle ip raw bytes inconsistently (ex we consistently marshal ipv6 format so exact match always works).
thoughts? @openzipkin/core
The text was updated successfully, but these errors were encountered:
to help with this, I can take an example trace and encode both ways in proto3 to see what the size difference is. then I can gzip it and see what the size difference is (many transports do gzip)
through various issues, seems proto3 is the preferred binary format for the span v2 model. We have some decisions to make, mostly around parity with ids and ips.
For example, we can choose to encode the hex ids as raw bytes (half the size of them)
We can also choose to encode IP addresses literals as raw bytes (sliding scale for ipv6; always smaller for ipv4)
Main thing is that if we do choose a binary encoding for proto3 ids and ips, there's a chance users will encode IDs incorrectly (ex encode IDs as uppercase hex, or '0x' prefixed or worse base64). There's a chance folks will handle ip raw bytes inconsistently (ex we consistently marshal ipv6 format so exact match always works).
thoughts? @openzipkin/core
The text was updated successfully, but these errors were encountered: