If you were to ask any Prolog programmer why they develop their applications in Prolog, they would at some point mention the backtracking capabilities of the language. It would therefore be largely unthinkable to develop a Prolog application without using such an ability. It is considered a strength too important to lose and the one reason why Prolog has proved a difficult language to interface to the Internet.

Although such backtracking capabilities are preserved within ProWeb, a number of overheads will have to be incurred and a certain programming style is imposed on the developer.

ProWeb keeps track of the current execution state for each client and uses this information to support backtracking through the search space to provide alternative solutions where appropriate. Due to the www asynchronous nature, getting to the correct continuation point in a conversation is especially hard. The Prolog language has conventionally dealt with such a situation through a mode of operation known as the save state model.

This ProWeb adopts a different mode of operation the recompute model. With this model, your application is re-run from the beginning every time a response is received from a client. With the recompute model, an overhead in execution time is incurred as some of the code within your application is executed many times; substantial acceleration can be achieved however because ProWeb allows partial solutions, computed and stored in one run through, to be retrieved in the next. ProWeb uses this method itself to ascertain which pages have already been sent to a client and what answers were given to which questions.

The save state model may be incorporated into a later release of ProWeb, to be used instead of or alongside the recompute model; any code you develop will be unaffected by this change. Despite removing the overhead in execution time, the save state model possesses its own overhead, that of requiring the server to have a large amount of hard disk space.