I've been designing a custom binary format for describing, storing, and transmitting data. It's mainly intended for future personal projects, and I plan to write a parser for it when I have time. The specification is fairly detailed, but the original document link may not be working correctly. I'd appreciate feedback on whether the design is practical, overly complicated, or suffering from scope creep. In particular, I'm interested in whether the format has a clear purpose and what advantages it might offer compared with established options such as Protocol Buffers, Thrift, Avro, or similar formats.
2 Answers
Before reviewing the technical details, make sure the specification is accessible and provide a short overview of the format. It would help to know whether the focus is compact storage, fast parsing, schema flexibility, portability, human-friendly tooling, or something else. Without that context, it's difficult to judge whether the complexity is justified.
The specification seems thorough and is laid out in a way that feels familiar for a binary format. The biggest missing piece is the motivation: what problem is this solving, and why should someone use it instead of an established alternative? Explaining the intended use cases, design goals, trade-offs, and expected advantages would make the proposal much easier to evaluate.
That makes sense. I'm aiming for a general-purpose format for describing, storing, and transmitting data, but I haven't found a concise name or clearly stated purpose for it yet. Calling it a binary data description and storage format may be more accurate.