Inverting back the inversion of control (2003) [pdf]

That was my first take too. There was a lot of awful middleware in the 1993-2007 or so period that were heavy in back-end state. Something close to the continuation style is binding a process or thread to the session id. For instance, the library management system Voyager had a telnet interface that they hacked a front end onto.

One trouble with that kind of system is each session requires a lot of memory so you have to implement a timeout and no matter how long you make the timeout, users are going to be mad if they got through 15 pages of forms, had to wait on hold on the phone to get the information for page 16 and then they lost it. People expect to be able to walk away from Microsoft Word on Friday and still be able to use it on Monday, etc.

Continuations are much more memory efficient but still have challenges. I am having a lot of fun with python asyncio, but you can't pickle tasks out of the box so you can't migrate tasks between servers on a cluster, reload them after a crash, flush them out of memory if memory is tight, etc.

That is one option, but you can also architect the system such that the client holds most of the state either in the URL or in a hidden field (signed by the server to prevent tampering, and optionally encrypted). You'll still need the server to track some aspects of the session, for example to prevent accidentally submitting the same order multiple times.

Just the other day someone posted something here about defunctionalizing continuations. That's the way to go: whatever amount of state the server has to hold, you have to hold anyway, and clever defunctionalization will let you just hold that amount even with a continuation-based approach.

The concept of continuations is well-established and they have their uses. They have been part of the landscape for years. They can be confusing, and that's impossible to separate from their power.

The inversion of control that this paper is talking about is the way an application running on a webserver typically gets called by the browser rather than the other way around. Continuation-based webservers reverse this inversion and create an illusion of continuity of control flow on the server side. The application is suspended when a page is sent to the browser and resumed (via a continuation) when the response arrives. So this is about permitting server-side applications to be written in a nicer style as far as control flow is concerned.

I think you are getting downvoted because your comment more or less says that you don't know much about the background, and haven't read and understood the paper, but are inclined to dismiss it anyway.

Same here. when I read/see IoC my immediate thought was Java/Spring. And yes, for the most part IoC as a concept is dying. More and more developers want to hold a function that returns hammers. They don't want a hammer factory factory factory anymore.