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
Currently all definitions for the data types in isomdl / cose derive the Serialize and Deserialize traits from serde. This is for convenience since this gives us an easy way to convert to and from cbor.
The problem with this however is it also enables these structs to be converted to/from any representation that has a serde implementation, and many of these structs have cbor specific structure which would be lost when roundtripped through a non-cbor representation.
Another problem is that the serde traits lead to fallible conversion to cbor, which makes for more complicated logic in the code. We know that by definition are structs are always representable in cbor, so we could define trait(s) that allow us to always convert to cbor without erroring.
These are potentially small issues, so we should analyze whether moving away form serde to custom trait(s) is worthwhile.
The text was updated successfully, but these errors were encountered:
I don't think the fact that it could be misused and serialised to other encodings is something to be concerned about. Many libraries/applications are JSON specific but still use serde.
But yes, if I remember correctly we already decided that serde just doesn't play well with CBOR, and we've already moved away from it in other libraries?
Currently all definitions for the data types in isomdl / cose derive the Serialize and Deserialize traits from serde. This is for convenience since this gives us an easy way to convert to and from cbor.
The problem with this however is it also enables these structs to be converted to/from any representation that has a serde implementation, and many of these structs have cbor specific structure which would be lost when roundtripped through a non-cbor representation.
Another problem is that the serde traits lead to fallible conversion to cbor, which makes for more complicated logic in the code. We know that by definition are structs are always representable in cbor, so we could define trait(s) that allow us to always convert to cbor without erroring.
These are potentially small issues, so we should analyze whether moving away form serde to custom trait(s) is worthwhile.
The text was updated successfully, but these errors were encountered: