IP is stateless. TCP is stateful. HTTP is stateless. Web apps are stateful.
See a pattern?
HTTP is just one layer in a stack of protocols, some of which are stateful, others of which are stateless. Stateful protocols coordinate state at the endpoints by exchanging messages over stateless protocols.
A web application NEEDS to maintain state for the person using the browser. It does that by maintaining coordinating state in the browser and server by exchanging messages over HTTP. How stateful the application needs to be depends on the application. It's an engineering trade-off, not a religious belief.
I guess with respect to this specifically, I think the state should be stored explicitly by the application, not implicitly by the language or framework. In a continuation-based framework, state is captured in the form of the call stack, and stored transparently. Far too clever for me, and hides the developer from things the developer shouldn't and can't really be hidden from.# Ian Bicking
Isn't this just another example on varying level of abstaction in different systems? To pick couple of (hopefully) non-controversial examples:
- do you feel comfortable relying on operating system to store the state of your process?
- do you trust on language to handle memory management automatically for you?
Whether the abstraction fits into a particular task might also be just a matter of how well it fits into one's mental model of the problem :)# Tero Saarni
If the alternatively is manually coding in a spaghetti-ish continuation passing style-like way then give me continuations please.# Nico
If the alternative is manually coding in a spaghetti-ish continuation passing style-like way then give me continuations please.# Nico
The statement "the web is stateless" is a bit misleading, while I would have found something like "HTTP is stateless" more accurate. As said in the above comment, applications are usually stateful (they internally manage a link between a succession of events --HTTP requests--). HTTP requires the programmers to handle this state (the link between a sequence of HTTP requests) internally (which is done with cookies).
Take SIP for instance, you will see that this protocol explicitely stores state (the notion of "Transaction" and "Session" to which requests and sequences of request belong), which is quite helpful... but can also be done internally on top of HTTP.
Now, regarding continuations, they are simply a way to "slice" a process and to automatically weave and rejoin the slices together, so that the programmer does not have to carry the burden of finding where the program was last interupted. They offer a process-based (or "dynamic"-base perspective) as opposed to a state-based (or "static"-based) perspective, as it is the case with most framework.
So it's rather a matter of perspective, instead of a implementation -- and then I wouldn't say that this perspective is a dead-end, it is just different, and IMHO closer if not more fitted to the domain of communications, from which the Web stems.