ovidiu      02/02/27 17:33:09

  Modified:    src/scratchpad/schecoon/webapp/docs index.xml
  Log:
  Added short description on continuations.
  
  Revision  Changes    Path
  1.2       +82 -13    xml-cocoon2/src/scratchpad/schecoon/webapp/docs/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/xml-cocoon2/src/scratchpad/schecoon/webapp/docs/index.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.xml 10 Jan 2002 05:21:25 -0000      1.1
  +++ index.xml 28 Feb 2002 01:33:09 -0000      1.2
  @@ -3,20 +3,89 @@
   
   <document>
     <body>
  -    <s1 title="A new Cocoon sitemap implementation">
  -      <p>This page describes a new implementation of Cocoon's sitemap
  -      which dramatically increases Cocoon's start-up speed and the
  -      turnaround development time when writing applications using
  -      Cocoon.</p>
  -
  -      <p>The new sitemap implementation reads the sitemap at runtime
  -      and translates its XML format into a program written in the
  -      algorithmic language <link
  -      href="http://www.schemers.org/";>Scheme</link>. Each time you
  -      make a new request to Cocoon, the Scheme program representation
  -      of the sitemap will be executed.</p>
  +    <s1 title="Schecoon - Cocoon with control flow">
  +      <p>Schecoon is an attempt to add advanced control flow
  +      capabilities to Cocoon. Control flow is usually referred to as
  +      the ability to describe the order of Web pages that have to be
  +      sent to the client, at any given point in time in an
  +      application.</p>
  +
  +      <p>Traditional Web applications try to model the control flow of
  +      a Web application by imagining the application as a finite state
  +      machine (FSM). For a client, the application can be only in one
  +      state at a time. Any request the client sends to the application
  +      makes it transition in a different state. As a side-effect of
  +      this transition, the application may update internal data,
  +      either in memory or in the database. The response to this
  +      transition is a Web page that's sent back to the client.</p>
  +
  +      <p>For simple Web applications, this model works fine. However,
  +      as the application grows, the number of states and transitions
  +      between them grows as well, and it becomes hard to visualize
  +      what's happening in the application.</p>
  +
  +      <p>Moreover, the interactions in some applications are more
  +      complex than a simple finite state machine. In such cases it's
  +      much easier to think and implement the application as a program,
  +      rather than a FSM.</p>
  +
  +      <p>By using a high level programming concept called
  +      <em>continuations</em>, Schecoon tries to solve this problem,
  +      and promises to allow the control flow in Web applications to be
  +      modeled as a normal program.</p>
  +
  +      <s2 title="What are continuations?">
  +
  +     <p>A continuation is a way to represent what is the processing
  +     that still needs to happen. 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 program counter. You can not only store
  +     these things in the continuation object, but 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.</p>
  +
  +     <p>By resuming the processing stored by a continuation object,
  +     you essentially resume the program from the point it was
  +     stopped. This allows you to write programs that do something
  +     like this:</p>
  +
  +     <source><![CDATA[
  +    // some processing going here
  +    ...
  +->  send-page("response.xml");
  +    ...
  +    // some other processing here
  +    ...
  +]]></source>
  +
  +     <p>With continuations in the language, you can essentially
  +     store the continuation of <code>send-page</code> (think of all
  +     the stack trace, and the program counter), put it in a global
  +     hash table associated with an id. The id is then encoded in
  +     the <code>response.xml</code> page as an URL. When the user
  +     clicks on that URL, on the server side the associated
  +     continuation is resumed. Resuming the processing happens as if
  +     nothing was stopped, you get all the stack trace back, and all
  +     the local variables.</p>
  +
  +     <p>So instead of using beans to store things in session, you
  +     use normal variables in a program. Since each user has its own
  +     version of the program, all the local variables in the program
  +     are separate between users.</p>
  +
  +     <p>With this approach clicking the <em>Back</em> button in the
  +     browser is no longer a hassle to deal with for you as a
  +     server-side programmer. They will simply refer to past
  +     continuations objects, which have their own state of the local
  +     variables.</p>
  +
  +     <p>Since continuations are objects, you can also store them in
  +     a database, for really long-lived session, just like you do
  +     with session beans.</p>
  +      </s2>
   
  -      <p>More to come...</p>
       </s1>
     </body>
   </document>
  
  
  

----------------------------------------------------------------------
In case of troubles, e-mail:     [EMAIL PROTECTED]
To unsubscribe, e-mail:          [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to