[gawi]

Around the same period, in the telephony world, IVR (interactive voice response) systems entered the web universe with the VoiceXML W3C recommendation. It allowed IVR developers to write server-side web applications as ordinary web applications, the HTML being substituted by VoiceXML.

Given the very linear nature of an IVR dialog, it became clear that a continuation-based approach would greatly simplify development, as mentioned in the article.

The Nu Echo "Rivr" Java framework was created around this idea. However, since there is no native continuation in Java (yet!), it was approximated through thread-based coroutines.

The payoff for the developers is huge. It allows the developer to directly "map" a dialog specification to Java code. Abstractions can easily be introduced without having to create an explicit model for the state (the state is just the set of the variables and objects referred by the thread). This approach is much more flexible than state-machine based paradigms.

Even though all architectural issues mentioned here are valid (namely the lack of session-based fault-tolerance), it turned out to be somewhat manageable in real-life situations because in this type of system, there is a limited number of calls handled simultaneously and their average duration is typically a few minutes.

Rivr is still used today and we are currently defining mechanisms with HAProxy to implement no-downtime scenarios in Kubernetes.