I want native CBOR Support
Submitted by Brad Isbell
Permalink https://webwewant.fyi/wants/602eadc2a6174300d5585008/
This idea is currently being discussed.
CBOR is a standardized binary structured data format, akin to JSON, with additional benefits:
- Efficient storage of binary and numeric data types
- Data types such as Date can be stored directly
- Extensible with future data types, while maintaining backwards compatibility (https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml)
- It's inherently streamable (similar to NDJSON in that it's easy to skim a stream of objects as there is no top-level enclosure)
CBOR was first published in RFC7049 in 2013. Some editorial improvements have been made, with the current standard published at RFC8949
The format is well supported, with implementations in most all commonly used languages: http://cbor.io/impls.html
Use cases include:
- Encoding binary file data inside a structured object for API-like calls without base64-encoding the payload or cross-referencing multipart MIME. (There are a handful of questions per-day on Stack Overflow about base64 encoding file data so that a file upload can be kept in context of an object being sent to a server. This is horribly inefficient.)
- Encoding/decoding all of the data types modern JavaScript engines support, including typed arrays.
- Efficient and extensible web tokens with CWT
Currently, we can work around the problem by loading a CBOR JavaScript library to encode/decode. However, I believe a native implementation would have performance improvements. At a minimum, we wouldn't need to load a library.
I propose that a standard CBOR encoder/decoder be implemented, with support for all of the datatypes supported by JavaScript.
The ubiquitous availability of JSON is what made JSON a popular choice. CBOR's benefits make it better choice for most applications. If CBOR were natively available, I have no doubt that it would be used much more broadly.
- Votes
- 0
What are votes for and how are they tallied?