What is this?

Distributed Processes are sequences of actions to be taken by multiple parties; in the example of an online purchase, the parties would be a customer, a web shop, a bank and a delivery service. The process between such parties would look like this:

1. Customer selects products
2. Web shop makes offer
3. Customer accepts offer through a bank order
4. Bank confirms payment to Customer and Web shop
5. Web shop ships the selected products to Delivery service
6. Delivery service brings product to Customer
7. Customer accepts product
8. Deliver service reports delivery-done
9. Customer expires on reasonable return time

A process like this involves steps to be taken by any number of parties. It is possible to set timeouts on steps that take too long to complete, and raise warnings. But normally, things should continue in a normal flow.

It is common to send emails when most of these steps are taken, but automation could greatly improve our experience here. Simply let the process take its natural course, be able to inspect it and receive updates on every step taken. Only when actions are needed from your as a customer would there be a need to see something popup.

Similarly for returning payment processes, and perhaps the ability to end a paid subscription. Such processes are ideally scheduled, and trigger an action from the consumer only when required. Again, let the normal flow act as it should, let the actors automatically update each other, but be able to step in or overview what is happening.

What this needs

To make this possible, a system is needed for distributed process control. A party that takes a step should actually be able to act, and inform others about it.

A proper set of specifications, at the right level of abstraction, can be quite helpful to fulfil this. Moreover, those specifications could define where to put in timing requirements, contact forms for various ways of action, and so on.

This is an IETF process, making it rather involved. The quality assurance processes in the Internet Engineering Task Force are high, and so is the flow of feedback to process and ponder, making specification design an excessively useful but difficult process. This is why this particular part of the Reservoir may well be the most difficult; but it is also likely to be one of the most useful and refreshing aspects!