I've been working on a CBOR encoder/decoder too and it's a fun project. Yours seems more advanced, I may help (if I find time to work on the project that needed CBOR in the first place :D).
One pain point about CBOR is extentions. There are a lot of them, some are widely used, meaning that any implementation that don't support them is almost never usable. The most problematic one is #25 (reference the nth previously seen string) which is:
useful (compress the data, a lot sometimes)
used everywhere
Forces to switch to a context-aware parser (unbound space and time, bleh!) :(
Another question I had at the time is which encoding/decoding API should the lib expose? Doesn't Zig need a common interface for serialization/deserialization à la Rust's serde?
To be honest, I haven't thought about adding extensions so far because my main goal was to work with CBOR data used in CTAP2/ WebAuthn (FIDO2). Due to resource limitations data used with FIDO2 is only allowed to use a subset of the RFC specification (e.g. items with unknown length are not permitted).
To your question: I stuck with the decode(cbor)/ encode(data) api most implementations use. Another approach would be to mimic the JSON api. I want to add serialization from and to structs in the future so I'll probably implement something like cbor.stringify(my_struct, .{options}, string.writer()) and cbor.parse(my_struct, &stream, .{}). I don't think there is an official interface pattern to use at the moment but xyz.stringify and xyz.parse are probably what comes closest. But I'd ask on the discord server to be sure.
Feel free to open a pull request if you want to contribute.
For further actions, you may consider blocking this person and/or reporting abuse
I've been working on a CBOR encoder/decoder too and it's a fun project. Yours seems more advanced, I may help (if I find time to work on the project that needed CBOR in the first place :D).
One pain point about CBOR is extentions. There are a lot of them, some are widely used, meaning that any implementation that don't support them is almost never usable. The most problematic one is #25 (reference the nth previously seen string) which is:
Another question I had at the time is which encoding/decoding API should the lib expose? Doesn't Zig need a common interface for serialization/deserialization à la Rust's
serde?(EDIT: #29 -> #25)
Hi, thanks for your comment :)
To be honest, I haven't thought about adding extensions so far because my main goal was to work with CBOR data used in CTAP2/ WebAuthn (FIDO2). Due to resource limitations data used with FIDO2 is only allowed to use a subset of the RFC specification (e.g. items with unknown length are not permitted).
To your question: I stuck with the decode(cbor)/ encode(data) api most implementations use. Another approach would be to mimic the JSON api. I want to add serialization from and to structs in the future so I'll probably implement something like
cbor.stringify(my_struct, .{options}, string.writer())andcbor.parse(my_struct, &stream, .{}). I don't think there is an official interface pattern to use at the moment butxyz.stringifyandxyz.parseare probably what comes closest. But I'd ask on the discord server to be sure.Feel free to open a pull request if you want to contribute.