Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Continuity: Continuation-Based Web Applications

by awwaiid (Friar)
on Jan 20, 2005 at 23:00 UTC ( #423821=perlmeditation: print w/replies, xml ) Need Help??

I've been delaying with this one -- hoping that I could get it a little more finished before mentioning it. But I've decided that what I really need is brainpower and feedback from my fellow monks. So sorry if this is a bit muttled... I just want to get it out there.

In case you haven't heard of it, continuation-based web programming is a neat trick for building stateful applications on top of the statelessness that is the web. It is a conceptual change -- imagine that your program is running in a direct interactive environment, on the command line for example. When you prompt a user for input, your program hangs until the user enters something, and then continues on the next line.

You might have:
print "Enter the first number: "; my $a = <>; print "Enter the second number: "; my $b = <>; print "The sum of $a and $b is " . ($a + $b) . "\n";
or similar. So, using continuations, we could do this in a web environment like this:
sub addTwo { my ($self) = @_; my $a = $self->getNum("Enter first number: "); my $b = $self->getNum("Enter second number: "); $self->disp("The sum of $a and $b is " . ($a + $b)); }

In order to set all this up, I first had to give perl continuations. We have Coro::Cont, but I couldn't figure out how to save these continuations to disk (which is necessary for my desired model, which is running through apache). So I created fake pure-perl continuations with Contize. Thats a story unto itself.

Once I had Contize, it was a short trip to create Continuity, which is the whole framework. This is already functional, though there are some known-issues (mostly with suspending objects to-disk, not as easy as it first may seem). I have some larger examples on my website, and I'm looking for others to try this out and help me find/fix the weaknesses.

Here is some more source to give you the idea:

##### --- ---- #!/usr/bin/perl use strict; use Continuity; use Guess; my $c = new Continuity( appname => 'Guess', print_html_header => 1, print_form => 1, ); $c->go(); ##### --- ---- #!/usr/bin/perl package Guess; use strict; use base 'Continuity::Application'; sub setNumber { my $self = shift; $self->{number} = int(rand(100)) + 1; } sub getNum { my $self = shift; my $f = $self->disp(qq{ Enter Guess: <input name="num"> <input type=submit value="Guess"><br> }); return $f->{'num'}; } sub main { my $self = shift; $self->setNumber(); my $guess; my $tries = 0; print "Hi! I'm thinking of a number from 1 to 100... can you guess i +t?<br>\n"; do { $tries++; $guess = $self->getNum(); print "It is smaller than $guess.<br>\n" if($guess > $self->{numbe +r}); print "It is bigger than $guess.<br>\n" if($guess < $self->{number +}); } until ($guess == $self->{number}); print "You got it! My number was in fact $self->{number}.<br>\n"; print "It took you $tries tries.<br>\n"; print '<a href="">Play Again</a>'; } 1;

And the live version of the above is at Also see the website for the project,

Update: Fixed demo URL.

Replies are listed 'Best First'.
Re: Continuity: Continuation-Based Web Applications
by gaal (Parson) on Jan 20, 2005 at 23:37 UTC
    What happens when the user hits 'back'?

      Excellent question.

      Right now, in my beta-ish stage, I am saving all continuations. Yup, allofem. So when they hit 'back' they go back in time to a previous state and can continue from there. Or they can split into two browsers and each get their own branch, etc.

      In the future I will add some management stuff for the application to access. The idea is to have a call which says "ok, now that I'm done processing their credit card, delete all the previous states so they can't go back and do it again on accident".

        This unfortunately doesn't solve the stickiness problem of (say) a shopping cart: you don't have a way to back-propagate adding an item to a cart to the old continuations. You could can have them just keep pointers to state, not the state itself, but then you end up needing to maintain that too, which is something continuations set out to avoid.

        Don't get me wrong, I'd love for this stuff to work magically well and let us be rid of the pain that is application programming over a stateless protocol. Maybe continuations have their place in the infrastructure of the Non Sucking Web. But they're not all that's required.

Re: Continuity: Continuation-Based Web Applications
by t'mo (Pilgrim) on Jan 21, 2005 at 14:44 UTC

      That, and a lot of other random things I've read. Also see another great framework, Seaside2, for smalltalk --

Re: Continuity: Continuation-Based Web Applications
by dragonchild (Archbishop) on Jan 24, 2005 at 15:06 UTC
    I've always thought that this would be an neat way to program websites, especially after reading Paul Graham's articles. The problem I see is that you're going to start spending more time in each request serializing and deserializing your continuations vs. actually serving up the request.

    Not to mention that most corporate websites aren't a single continuation - they're groups of vaguely related continuations. How would you handle the situation of where someone has done 10 clicks in one area, then clicks on the navbar to go to a completely unrelated area? Say, going from "Reports" to "Messaging" ... do you continue to handle the continuation from "Reports" every pageview while the user is going through the "Messaging" continuation?

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

      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 :)

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://423821]
Approved by erzuuli
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (3)
As of 2022-06-26 10:57 GMT
Find Nodes?
    Voting Booth?
    My most frequent journeys are powered by:

    Results (85 votes). Check out past polls.