Bill de hÓra on REST:
REST is about design constraints -- what you can't say. That's contrary to industry practice, where it's all about about getting cool new features piled on, and to heck with principles. If anything, most developers are cynical about architecture and architects. Developers, Developers, Developers. Give 'em what they want. Keep ornamenting the stack with pointy-clicky solution cruft.
There'll be a bit less of that. On the web, there are less assumptions you can make and those you can make are rigid and need to be treated as invariant. Developing for the web, as opposed to developing around it, is spartan work. Coming from middleware and enterprise development, could be a bit like coming from the Victorian ornateness and richness of Ruskin and Morris to the urban cold and minimalism of le Corbusier and Mies van der Rohe. It'll be disorienting at best.
This is why I think that continuation-based frameworks (Seaside being the quintessential example) are a dead-end. They are a giant workaround for the web. (Even Paul Graham thinks so, and it seems he may have invented the technique... but I shouldn't really present his off-handed remark as more than it is.)
The web is events. And asynchronous. And stateless. And you need to know this, you need to internalize this model as a programmer to work with the web. It isn't a GUI. So I don't think these (extremely clever) continuation-based synchronous layers on top of the asynchronous web are a good direction.
So what about the people that are trying to work around the statelessness by not closing the connection? Is comet a dead end?
It doesn't completely work around the http model in all scenarios, but it does have a fairly significant impact on how you think about communications while dom scripting.
I find vanilla web restrictive too, that's why I use Flash to maintain some state.
# Kevin Deenanauth
Er - you know that the internet is more than the web, right? For instance, I do a lot of code based on top of twisted, and a very, very small amount of it is web-based.
The approach used in something like twisted is still useful, even if the web didn't suck.
# Anthony Baxter
I don't think Twisted's use of continuations looks much like Seaside's. Twisted is very explicit about where a continuation is formed and returned (via Deferreds), while in Seaside it is entirely implicit. CherryFlow is the only system I'm aware of that does Seaside-style continuations (using Stackless).
# Ian Bicking
I should amend that -- Twisted's Athena probably is more like Seaside, though (I only know about them indirectly). But I also presume Athena is strictly for the web.
# Ian Bicking
Athena is a Divmod project, and has very little to do with Twisted (other than the fact that it uses it as a library).
# Moe Aboulkheir
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.
# Nat
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.
There is a conversation between Marco Baringer (who has written his own continuation based web framework) and Dave Roberts that you might find interesting: http://common-lisp.net/project/ucw/docs/html/rest/rest.html
# anonymous
I would realy like to know how this (apperently) stateless commenting system is working. Usualy I would imagine that my comment was stored somewhere as part of the state of the program that generates this webbpage. But as the net is stateless i guess thats wrong. But I just cant grasp how else it could work.
# anonymous