mitsuhiko / deser

Experimental rust serialization library
https://docs.rs/deser
Apache License 2.0
287 stars 8 forks source link

Buffering vs State #20

Open mitsuhiko opened 2 years ago

mitsuhiko commented 2 years ago

At the moment the idea is that serialization and deserialization happens without (significant) buffering. The only type of buffering the system currently likes to support is a single key at the time. This way there is a clear communication channel between the state and the current value which permits things like deser-path to function.

Unfortunately there are deserialization scenarios where this just does not work. For instance if the discriminant for a tagged enum is supposed to be serialized directly into a JSON object as key one needs to buffer the entire object during deserialization.

Example:

struct Obj1 {
  one: u32,
}

struct Obj2 {
  two: u32,
}

enum Foo {
  A(Obj1),
  B(Obj2)
}

This could have this representation:

{
  "one": 1,
  "type": "A"
}

There are two general possibilities I see for this:

  1. not supporting this type of serizalization format (when using state). That's not ideal but potentially acceptable as keeping track of things like paths in the state is not a particularly common situation
  2. make a subset of the state copy on write and buffer it together with the value. This would allow things like path tracking to have its state persisted in the buffered content