Re:The Unreasonable Effectiveness of Simple Binary Encoding ...
by robertlagrant on Wednesday August 09, 2023 @08:05AM
(#37061406)
It's always worth noting that JSON compresses the hell out of repetitive key names, just as it did for the even more repetitive XML. It's nicer to have a bit packing format that means you get even better space usage, and you skip a compression step, but it works for a huge number of cases.
Re:The Unreasonable Effectiveness of Simple Binary Encoding ...
by distcs on Wednesday August 09, 2023 @08:35AM
(#37061712)
Yeah. The title is clickbait and the post describes what every other binary protocol used to be like before JSON took over.
Honestly I can't see what the point of the post is. If you create a protocol that is optimized for bytes, you will get a protocol that is optimized for bytes. It's a trivial tautology.
Re:The Unreasonable Effectiveness of Simple Binary Encoding ...
by lordnacho on Thursday August 10, 2023 @05:22AM
(#37073821)
I've used SBE and Aeron, can recommend.
The difference with SBE vs JSON is there's no need to serialize/deserialize anything. In SBE you literally just write in the value and read the value. You aren't turning bytes into text, which takes time and might require intermediate state (depends on what you're implementing).
It's almost like a non-format, because what could be simpler?
Re:The Unreasonable Effectiveness of Simple Binary Encoding ...
by samtho on Thursday August 10, 2023 @05:39AM
(#37073940)
This reminds me a lot of protobuf, just packing serial data based on type, specified width combined with a specified length (like an array) when 9-n items are possible.
Honestly I can't see what the point of the post is. If you create a protocol that is optimized for bytes, you will get a protocol that is optimized for bytes. It's a trivial tautology.
The difference with SBE vs JSON is there's no need to serialize/deserialize anything. In SBE you literally just write in the value and read the value. You aren't turning bytes into text, which takes time and might require intermediate state (depends on what you're implementing).
It's almost like a non-format, because what could be simpler?
Something that specifies endianness and field types?