So in the existing continuation-based systems they "cheat" -- they don't serialize the continuation to disk on every request and get away with that by running their own webserver. The advantage is as you stated -- it has less overhead. But the disadvantage is when it comes time to serve your application off of a cluster, migrating continuations without serializing them is nontrivial :)

I'm pretty pleased with my solution. I serialize to disk, but I have a backup plan -- PersistentPerl (aka SpeedyCGI) or even mod_perl; then my serialize-to-disk is merely a backup, and I have a live version in memory all the time just like those other folks. Except I didn't have to write my own webserver.

For your second comment -- yes, websites aren't a single continuation. I have more in mind web-based applications... more like a tax-form assistant for example. Here, when you click on a breadcrumb to go back to the beginning or to another part of the application, you are implicitly saying "cancel what I'm doing, and go to this other place". The way I have thigns set up I can actually intercept such commands, to do such things as "Are you sure you want to leave this part of the application without commiting your changes?"

In any case I'm currently building a control-panel for a nonprofit webhosting place I helped start... so I am experiencing performance characteristics of a larger application first-hand. That has helped me work out the bugs quite a bit. So far its working out very well.

If anyone else is interested in working out some bugs by writing your own application using this stuff... just let me know :)