Add "HumanBinaryData" as an alternative to "Base64UrlSafeData" #354
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to issue #352, it doesn't fix things, but it's a start.
HumanBinaryData
uses a more efficient "bytes" format when using non-human-readable serialisation formats (like CBOR). The deserialiser still usesdeserialize_any
– I haven't got a great way around this yet.I've done a few things differently to
Base64UrlSafeData
; for example, this doesn't implementDisplay
orFromStr
– they're different to whatVec<u8>
does, and we should move away from this (this will be the focus of #356).It also implements
Deref
andDerefMut
, which should make the type more transparent – and all of the common impls are in macros.I've added
bytes
support toBase64UrlSafeData
, so it can read whatHumanBinaryData
produces. Unfortunately this makes migration a two-step process.While we're here, this makes
serde_json
a dev-dependency ofbase64urlsafedata
, because it's only used in tests; and this also adds a bunch more tests for expected input formats.