Scheme in Commercial Web Application Development [PDF] | Hacker News Reader

Scheme in Commercial Web Application Development [PDF]

untyped.com

34 pointsdt12 comments

Interesting to see they had the same problems in using continuations that bit pg with news.yc; you garbage collect them too early and the links in someone's browser stops working, too late and your server exhausts memory. Plus, it's trivial to do a DoS; just act like a newly arrived visitor to the site so a new continuation get created for you. See sections 4 and 5 in the PDF.

I can't see a good way around this as long as the server keeps the continuations instead of offloading it to the client.

I don't fully understand the use of continuations in web applications yet, what are they being used for? Are they an alternative to using transaction id's (avoiding the duplicate submission of forms)? I am not sure, but maybe making everthing more RESTful could help? Or maybe not...

One of the best uses of them is simply to make things modal. Consider an example from news.yc. Suppose you aren't logged into the site and you click on an uparrow. What normally happens is you get redirected to the login screen, login and get redirected back and/or actually vote. The whole thing looks something like this in code...

check to see if logged in; if logged in allow vote, else force login with a redirect;

And then you have to start from scratch after the redirect.

With continuations you can do this TRANSPARENTLY like this:

check to see if logged in and if not save my spot in the submit_vote computation, and "push" the login page; login and resume from where the login page was "pushed," thereby voting without redirecting and without restarting the computation.

Thanks - I have to admit, that is pretty neat ;-)

after rereading what I posted, I'm just glad you understood it. :)

REST is a broad term, which covers different ideas. One of these is that the statelessness of HTTP is an inherent aspect of web applications. Instead of trying to build abstractions, to hide this fact, (some) REST-proponents, will say that the only proper way to write web applications, is to avoid server side state, and instead rely on client side state. Continuations are in direct conflict with this principle.

Continuations captures state in a way very similar to closures. I think this is why the lisp/scheme crowd are so found of them. In contrast, the client-side-state-way appears procedural. I strongly believe that client side state is the _only_ worthwhile solution; We need to accept that fact and get rid of continuations.

> I strongly believe that client side state is the _only_ worthwhile solution; We need to accept that fact and get rid of continuations.

It's not clear to me if you're joking, but in case you're not: there are some situations, especially in closed-system webapps, where it's useful to use a non-transparent scheme for resources. You don't want people to jump into a middle page of a survey or other workflow, and going out of your way to have the middle pages accessible via a RESTful scheme seems pointless and potentially misleading. Continuations or similar methods for papering over the "page" abstraction can be helpful, here. Even if you don't use something like that, you'll end up doing the same thing manually.

I agree, though, that those who use this style typically overuse it and apply it to situations (like, er, discussion forums... ;) where it isn't really appropriate.

I'm part of the Lisp/Scheme crowd. I don't use continuations in my web development, but I think you're stating things too strongly to say they should never be used. I think it's easy to see the convenience of them, and rapid prototyping is important. When scalability becomes a big issue people will come up with a good way of serializing continuations.

You're right that most existing web application frameworks (targeted at lisp or otherwise), use some sort of server side state mechanism. But that is not to say, that a rapid prototyping framework couldn't be made, which used solely client side state.

Anyway, I am of course putting it a bit on the extreme end here, but in principle I stand by it. Continuations are but an elegant hack; I might prefer it over other similar hacks, but I'd rather not have to use it at all.

Is it continuations you don't understand or their use in web apps? If the latter then you can see them in use on this site when you click "reply". You get a URL ending /x?fnid=bU389jXsk2. That's a FuNction ID that allows the continuation to be eXecuted and run a bit further.

The site used to use them far more but because only the last N continuations were kept, at times of high load users would find the links on the page they were viewing broke on trying to use them; the fnid they referred to had disappeared because N more had been created since. One solution is to increase N. However, any trivial means of generating another M fnids means it's easy for a single attacker to cause N more to be generated.

As troels says, RESTful is the way to go. Continuation in my view are flawed for web apps. AIUI pg got away with it for Yahoo Store because they were only used in the shop design side of things where each shop owner could be given his own N storage of fnids, isolated from others.

It's been discussed before on here, in particular a post by me around end of April/start of May 2007 that caused pg to email me privately about thinking up new "ddos attacks". A while after that, most of the usage of fnids were replaced by conventional-style URLs so also some remain, M is smaller than it used to be.

I understand continuations, but I wasn't sure about their use in webapps.

I wish I could upvote you with 100 points ;-)

Reply on news.ycombinator.com