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
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.
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.
The text was updated successfully, but these errors were encountered:
I don't know much about this either, only that browsers already encode/decode CBOR for different internal use case (it looks like Gecko uses it for WebAuthn).
CBOR is a standardized binary structured data format, akin to JSON, with additional benefits:
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.
The text was updated successfully, but these errors were encountered: