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
{{ message }}
This repository has been archived by the owner on Aug 15, 2021. It is now read-only.
I'm confused as to why parsing tags out of CBOR is locked behind a feature. With it this way, the library clobbers valid CBOR messages in a way that makes no sense unless you look close enough to realize that it ignores the tag byte unless a feature is requested (which is not on by default and is poorly documented).
The text was updated successfully, but these errors were encountered:
The problem is that there's no clean way to represent tags in the Serde Data Model. Tag support is a hack to get it working and after spending quite some time on getting support for tags in, I no longer think they should be supported. If you have something with tags, you probably shouldn't use Serde.
Unfortunately, this makes serde_cbor pretty much useless for many applications that use CBOR. I think the distinction here is that there are two uses of CBOR within Rust. 1. is the Serde type use, where it is about serializing and deserializing what are essentially Rust data structures. The other use 2. is about handling specifications and data formats that use CBOR. I agree that tags don't really make much sense for case 1, but case 2 frequently makes use of tags.
Are you suggesting we should have another cbor crate that is designed to handle case 2? So far, I've been finding that using the Tagged type and some custom serialize/deserialze code I'm able to use this crate to handle pre-defined data formats quite well. The main difference so far, is that most custom formats use integer tags for structs, instead of strings of the field name.
I'm confused as to why parsing tags out of CBOR is locked behind a feature. With it this way, the library clobbers valid CBOR messages in a way that makes no sense unless you look close enough to realize that it ignores the tag byte unless a feature is requested (which is not on by default and is poorly documented).
The text was updated successfully, but these errors were encountered: