Source code and documentation: https://bitbucket.org/reginleif/solid-engine/src/master/
Problems and solution concept
HTTP-protocol is stateless. If we want to do complex actions, for example: wizard dialog on the series of pages or, more importantly, manage presentation from server, we must save intermediate state. For storing state can be used some techniques: storing session in database or server memory, storing some data on page by using async requests or by using cookies. All of that techniques have their drawback, storing data on client fraught with security breach, storing session in server memory imposes restrictions on the amount of memory and in addition there is a need to keep track of the lifetime of a session. Moreover, the user will not be able to visit the page after the expiration of the session. There is a need to restore the state by information available in the URL. In addition to this problems, an effective mechanism is needed to control the presentation from the server (application controller).
Solid-engine is developed to solve this problems. What is a application controller you can read from Martin Fauler "Patterns of Enterprise Application Architecture". The idea of implementation is bored from SICP (amb-operator). As opposed to amb-operator, where choice controlled by amb-operator, in Solid-engine choice provided by user. In point of program view, selection also non-deterministic --- developer just place choice points in controller code. If we imagine user's work in web-application as process, then we can code user's workflow as program code with points of choice in some places. In that places we have information about objects that user must select (from set of objects) or provide (simple type values) to continue execution. Each choice point is place where user must provide values for variables. Variable values for choice points is stack up and client must send it to server for execution. The response from server contains other stack, that client must sent with some additional user's input values. Received client's stack on provide variable values for choice points. Process of executing program start on each request and lasts until the stack is empty. Thereafter variables binding form send return information about stack and presentation. Stack on client can be stored in URL and form fields. To avoid repeating of server side-effect actions returned to client stack didn't contain information for visited (side-effect) code branch. Additional advantages is preserving context of logic execution, any additional checking not needed. Call stack playback eliminates possibility of wrong logic execution.
Implementation
Solid-engine is developed for use with HTTP-protocol, but fits for use with any stateless-protocol. It presentation- and server-agnostic. You can freely choose (web-)server and presentation layer by implementing thin integration code. For http-protocol choice stack can be stored in URL (as query parameters and parts of path) and POST-parameters.