Return-Path: Delivered-To: apmail-cocoon-docs-archive@www.apache.org Received: (qmail 66093 invoked from network); 30 May 2007 21:13:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 May 2007 21:13:47 -0000 Received: (qmail 54745 invoked by uid 500); 30 May 2007 21:13:52 -0000 Delivered-To: apmail-cocoon-docs-archive@cocoon.apache.org Received: (qmail 54661 invoked by uid 500); 30 May 2007 21:13:51 -0000 Mailing-List: contact docs-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: docs@cocoon.apache.org List-Id: Delivered-To: mailing list docs@cocoon.apache.org Received: (qmail 54650 invoked by uid 99); 30 May 2007 21:13:51 -0000 X-ASF-Spam-Status: No, hits=-99.5 required=10.0 tests=ALL_TRUSTED,NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [140.211.11.67] (HELO cocoon.zones.apache.org) (140.211.11.67) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 May 2007 14:13:51 -0700 Message-ID: <19174942.1180559606752.JavaMail.daisy@cocoon.zones.apache.org> Date: Wed, 30 May 2007 21:13:26 +0000 (GMT+00:00) From: daisy@cocoon.zones.apache.org To: docs@cocoon.apache.org Subject: [DAISY] Created: Continuations Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org A new document has been created. http://cocoon.zones.apache.org/daisy/documentation/1373.html Document ID: 1373 Branch: main Language: default Name: Continuations Document Type: Cocoon Document Created: 5/30/07 9:13:05 PM Creator (owner): Reinhard P=C3=B6tz State: publish Parts =3D=3D=3D=3D=3D Content ------- Mime type: text/xml Size: 3909 bytes Content:

A different approach

Web applications are essentially event-driven applications. Such applica= tions have to react to events generated from the client browser, and they respond= to these perhaps by changing their internal state and generating a response.

The result is that even a simple application that needs to collect some information from the user using more than one page, has to somehow maintain= the input accumulated so far from the user. This input is a characteristic of t= he application state. Another characteristic of the application state is where= the program processing is.

Let's look at an example. Suppose we want to write a very simple calcula= tor, which collects the numbers to be added, as well as the operator, each in a separate page. It would be very nice if we could write something like this:= 

function calculator()
{
  var a, b, operator;

  cocoon.sendPageAndWait("getA.html");
  a =3D cocoon.request.get("a");

  cocoon.sendPageAndWait("getB.html");
  b =3D cocoon.request.get("b");

  cocoon.sendPageAndWait("getOperator.html");
  operator =3D cocoon.request.get("op");

  try {
    if (operator =3D=3D "plus")
      cocoon.sendPage("result.html", {result: a + b});
    else if (operator =3D=3D "minus")
      cocoon.sendPage("result.html", {result: a - b});
    else if (operator =3D=3D "multiply")
      cocoon.sendPage("result.html", {result: a * b});
    else if (operator =3D=3D "divide")
      cocoon.sendPage("result.html", {result: a / b});
    else
      cocoon.sendPage("invalidOperator.html", {operator: operator});
  }
  catch (exception) {
    cocoon.sendPage("error.html", {message: "Operation failed: " + exceptio=
n.toString()});
  }
}

In this example, the calculator function is called to start the calculator application. We'd like the sendPageAndWait function to = be a special function, that takes as arguments an HTML file to be sent as respon= se, and some optional data that needs to be placed dynamically in it. We would = like sendPageAndWait to send the response page and then block the execu= ting thread, until the user clicks on a link in the response page, which sends a request back to the server. This request resumes the processing at the poin= t it was left, right after the call to sendPageAndWait.

This approach looks very powerful, since the flow of pages within the application can be described as a normal program. Using this approach you n= o longer have to think of your Web application as a finite state machine, whi= ch transitions from one state to another, and in the process generates respons= e pages.

A big disadvantage of the approach above is that we need to maintain a t= hread alive until the user hits the link on the response page. This is clearly ve= ry expensive!

It would be very nice if we could capture the state of the application, = its stack of function calls, which includes local variables, the global variabl= es and the program counter, and save them into an object. If this object would= give us the ability to restart the processing from the point stored in it, this = would be what we need!

What are continuations?

A continuation is exactly the type of object that we need. Think of a continuation as an object that, for a given point in your program, contains= a snapshot of the stack trace, including all the local variables, and the pro= gram counter. You can not only store these things in the continuation object, bu= t also restore the execution of the program from a continuation object. This = means that the stack trace and the program counter of the running program become = the ones stored in a continuation.

Continuations are powerful concepts from the world of functional languag= es, like Scheme, but they are becoming popular in other languages as well.

Collections =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The document belongs to the following collections: cdocs-core