3 ms·

I'm not sure what you mean by continuation-based. The Arc server can use closures to store state, but it doesn't use continuations. Using closures to store st

by pg 14y ago

I'm not sure what you mean by continuation-based. The Arc server can use closures to store state, but it doesn't use continuations. Using closures to store state is like using lists as data structures: it's a rapid prototyping technique. You're in no way painting yourself into a corner, and the current news software is proof of that. You have a very old version of it. In the years since we released the version you have, we've gradually squeezed most of the closures out of the more common things, and we do have a proxy in front of the Arc server. That's how we manage to serve 1.7 million pages a day off one core.

akkartik 14y ago
I see. Yeah, I stand corrected. I was conflating continuation-based and closure-based webservers because both allow straight-line code instead of explicitly managing url handlers. And the traditional rhetoric in favor of this technique has come from Seaside, which popularized the name 'continuation-based' (http://www.linux-mag.com/id/7424 http://www.linux-mag.com/id/7424; http://www.bluishcoder.co.nz/2006/05/server-side-javascript.html http://www.bluishcoder.co.nz/2006/05/server-side-javascript....) I'd never seen anybody say this is just an early-prototyping technique. But searching found Patrick Collison concur: http://www.quora.com/Whats-the-best-continuation-based-web-framework http://www.quora.com/Whats-the-best-continuation-based-web-f... It was too harsh to say it paints us into a corner; it is possible to replace fnid links with new defops. I went back and looked at the frontpage when not logged-in, and saw that there are 0 fnid links in that common case. (One possible way to gradually use a second server would be to just serve the frontpage off it. You'd need to move to a centralized store for user/profile/story objects, but the fnids table could continue to live on one server.) It also turns out that there's at least one company trying to scale continuation-based servers (http://bc.tech.coop/blog/040404.html http://bc.tech.coop/blog/040404.html). So it was overly harsh to call it a dead end.
jsgrahamus 14y ago
PG: It could be instructive to be able to compare your new version with what is currently available.

by pg 14y ago

akkartik 14y ago

I see. Yeah, I stand corrected. I was conflating continuation-based and closure-based webservers because both allow straight-line code instead of explicitly managing url handlers. And the traditional rhetoric in favor of this technique has come from Seaside, which popularized the name 'continuation-based' (http://www.linux-mag.com/id/7424 http://www.linux-mag.com/id/7424; http://www.bluishcoder.co.nz/2006/05/server-side-javascript.html http://www.bluishcoder.co.nz/2006/05/server-side-javascript....) I'd never seen anybody say this is just an early-prototyping technique. But searching found Patrick Collison concur: http://www.quora.com/Whats-the-best-continuation-based-web-framework http://www.quora.com/Whats-the-best-continuation-based-web-f... It was too harsh to say it paints us into a corner; it is possible to replace fnid links with new defops. I went back and looked at the frontpage when not logged-in, and saw that there are 0 fnid links in that common case. (One possible way to gradually use a second server would be to just serve the frontpage off it. You'd need to move to a centralized store for user/profile/story objects, but the fnids table could continue to live on one server.) It also turns out that there's at least one company trying to scale continuation-based servers (http://bc.tech.coop/blog/040404.html http://bc.tech.coop/blog/040404.html). So it was overly harsh to call it a dead end.

jsgrahamus 14y ago

PG: It could be instructive to be able to compare your new version with what is currently available.