Schema design

[iboB]

The session has a current state. The state defines what inputs are acceptable at this point and what outputs can be produced. In order to shape their I/O code, the client has to have knowledge of the server's implementation. The schema's job it to formalize the propagation of this knowledge.

Current Implementation

The server notifies the clients upon state changes with a state-change frame, which includes a single string of the state's id.

The schema then describes a state as composed of:

• id: string, received with the state-change frame
• ops: operations which can be performed on the state. Ops are composed of:
  • params: format of frame that is sent to the server to "start" the op
  • return: format of frame which is received when the op completes. It can be null (as in a void function).
• inputs: format of frames which can be sent to the server. Similar to op, but no response is provided. Useful for streams
• outputs: format of frames which the server can send at any point. Useful for streams

Additionally an error frame can be sent from the server at any point.

Problems

1. Replication problems which we're willing to live with for now discussed here Schemas, state, and state replication #235
2. return can't be a state-change frame. This means that when running an op which changes the state, two frames should be expected as a response: return (likely null) and then state-change. This makes the code unpleasant: push(op), poll(null), poll(state-change)
3. if the state has outputs there is no way to know when the return of an op will be received. In such a case it is not guaranteed that the frame received after initiating an op will be its return. It could be one of the output frames.
4. Errors don't have a formal relation to their cause. If an error is received it is not known whether it's as a response to an op, or something else.
5. Frames don't have a formal relation to the sate in which they were created. If a server changes its state, some frames may come which were issued for its previous state and make no sense (or worse: make the wrong kind of sense) here.

Thoughts

There exists a fine balance between solving these problems and making the schema too complicated or too restrictive.

For example. I think that problems 3-5 should not be covered by schemas and frame formats, but I think problem 2 is really unpleasant and should be solved