postcard-dyn: reserialize into arbitrary Serializers #194
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.
Implements a
postcard-dyn
"reserializer" that deserializes postcard-serialized data and feeds it into an arbitrarySerializer
in a streaming fashion (without needing to construct an intermediate representation in memory). I think this is (or could be) fully lossless. This meanspostcard -> serde_json::Value
(or whatever generic representationpostcard-dyn
ends up providing),postcard -> json
, and arbitrary otherpostcard -> X
transformations can be performed by the same generic implementation.A few implementation limitations:
Serialize
methods require&'static str
s for structs/variants/field names. To provide these, the current implementation allocates and leaks one copy of each unique string that must be used as&'static
. I can't find a way around this that isn't lossy and this seems inevitable in order to provide aSerialize
ablepostcard_dyn::Value
.Serialize
able struct that does the deserializing, which is the most straightforward way I found to implement the transformation. However, this means methods only receive&self
, which necessitates use ofRefCell
for getting exclusive access to theFlavor
.@jamesmunns wanted to get your thoughts before I put more work into it. I think it's promising, but the first limitation is... rather limiting.