Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buffering vs State #20

Open
mitsuhiko opened this issue Feb 11, 2022 · 0 comments
Open

Buffering vs State #20

mitsuhiko opened this issue Feb 11, 2022 · 0 comments
Labels
design Design considerations

Comments

@mitsuhiko
Copy link
Owner

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
@mitsuhiko mitsuhiko added the design Design considerations label Feb 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design considerations
Projects
None yet
Development

No branches or pull requests

1 participant