Split from #49 (which is now scoped to session resurrection — the near-term, serialization-free half).
What this issue is: making page state survive restarts, i.e. serializing (some of) the page cache. Deliberately parked until Java's marshalling work (the Amber serialization successor) ships, for reasons that go beyond convenience:
- Building on
java.io.Serializable in a new framework means taking a fresh dependency on a mechanism its own platform wants to replace.
- Marshalling's published design — constructor-based reconstruction, explicit opt-in, data-oriented, records-first — matches ng's design principles (construction-order principle, explicitness) so closely that waiting gets us a mechanism that fits instead of one we fight.
- Serialized session/page graphs are a cross-version compatibility contract: every persisted framework internal taxes every refactor. The render redesign, request-cycle model completion and page-cache scope tree should all land before any such contract exists.
- Convergence: by the time marshalling ships, the scoped-retention work (task scopes with explicit state) should have made session state data-shaped — marshallable by construction rather than by heroics.
The skeptical scope, stated up front: even with marshalling in hand, this should be expanded resurrection, not byte-exact graph persistence. Serializing a component instance referencing a thousand Cayenne DataObjects is not a good use of resources — the sane unit of persistence is the compact facts a page/task can be rebuilt from (task-scope state, identifiers), reconstructed through constructors against live data. Apps should meanwhile be designed to reduce their reliance on stateful pages; the framework's direction (task scopes, stateless-by-default, action references) actively helps.
Dependency: #47 (NGSwitchComponent redesign) must land before any cross-restart page/session survival — the current first-encounter-order elementID minting is traffic-dependent and becomes silent wrong-component dispatch the moment old senderIDs meet a restarted JVM.
Split from #49 (which is now scoped to session resurrection — the near-term, serialization-free half).
What this issue is: making page state survive restarts, i.e. serializing (some of) the page cache. Deliberately parked until Java's marshalling work (the Amber serialization successor) ships, for reasons that go beyond convenience:
java.io.Serializablein a new framework means taking a fresh dependency on a mechanism its own platform wants to replace.The skeptical scope, stated up front: even with marshalling in hand, this should be expanded resurrection, not byte-exact graph persistence. Serializing a component instance referencing a thousand Cayenne DataObjects is not a good use of resources — the sane unit of persistence is the compact facts a page/task can be rebuilt from (task-scope state, identifiers), reconstructed through constructors against live data. Apps should meanwhile be designed to reduce their reliance on stateful pages; the framework's direction (task scopes, stateless-by-default, action references) actively helps.
Dependency: #47 (NGSwitchComponent redesign) must land before any cross-restart page/session survival — the current first-encounter-order elementID minting is traffic-dependent and becomes silent wrong-component dispatch the moment old senderIDs meet a restarted JVM.