Skip to content

Buffering vs State #20

@mitsuhiko

Description

@mitsuhiko

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    designDesign considerations

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions