
Inverting back the inversion of control (2003) [pdf] - tosh
https://pages.lip6.fr/Christian.Queinnec/PDF/www.pdf
======
jrochkind1
Am I misunderstanding, or would this require the server to hold state for
every client that has been delivered a form, but not yet received a form
submission?

That seems like a bad architecture for a web app.

A long time ago I wrote web apps in WebObjects (originally NeXT, then Apple).
While it didn't use continuations, it _did_ rely on maintaining server state
for every client, in order to try to make writing a web app transparently as
much like writing a 'native' (we didn't call them native then) app as
possible. That aspect of architecture -- persistent client-specific state on
the server meant to be tracking what the client was doing -- was a fundamental
mismatch for the web, and led to lots of complexity and problems. While it
seems like it can/should be transparent/automatic (and that was the intent of
the WebObjects archiecture), it ends up an abstraction with significant leaks,
just because it's such a poor match for the mostly stateless web client-server
architecture.

~~~
PaulHoule
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.

------
jkingsbery
It's not immediately obvious what this has to do with Inversion of Control.

I didn't really know much about continuations, but from what I can gather it's
not obvious they're a good idea ([http://okmij.org/ftp/continuations/against-
callcc.html](http://okmij.org/ftp/continuations/against-callcc.html)) - Ruby
removed it's in-built support for it ([https://bugs.ruby-
lang.org/issues/10548](https://bugs.ruby-lang.org/issues/10548)).

~~~
theoh
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.

~~~
arethuza
Doesn't HN run on Arc which can use continuations for handling some web stuff?

[https://arclanguage.github.io/ref/srv.html](https://arclanguage.github.io/ref/srv.html)

NB I've never looked at the sources for HN

