Schemas, state, and state replication

[iboB]

The current way we deal with schemas is for them to be basically lists of states. A state defines it's io (ops, streams).

There have been a number of ideas which for lack of good ways to implement have been postponed (or maybe scratched):

• unassuming state replication - the possibility for a client to know full description of the server state at any point. This would mean serializing the state on change, so that even if a client doesn't have the schema, it can still determine the io profile of the server. Very complex to do and seems rarely used.
• schema-level state graph - a graph which represents possible state transitions in a provider schema. This is even not too hard to implement, but it would be very demanding both for state authors and consumers. The description of invariants tends to grow out of control and the benefits of this information are minimal (probably most notably when implementing the server session handler). Ideally it can be inferred, but that's a very complex task. Scratched for now.
• formal frame-state relationships - this would mean having code of our own which allows the association of a frame with the state in which it was produced. This can be used to solve some potentially unpleasant async problems (abort is sent, but what is being aborted?). This is complex to implement and demanding to use for both sides. It can be solved on a per-case basis if needed. Instead we should focus on implementing resilient states, which won't suffer from the lack of this information.

These decisions may be revisited in the future. For now they greatly reduce the scope of #226, #233, #234