Name: Anonymous 2012-09-17 1:50
http://continuity.tlt42.org/Perl.com_Article
--------------------------------------------
Continuations are awesome. Mention Seaside. Perhaps get a dig in on fake continuations (they call them "Delimited Continuations" but even this is not true IMO) in Jifty.
Continuations are not perfect. Especailly since they're really co-routines (even I lie when I say that I have continuations). Memory overhead, non-core feature.
Continuations are fantastic. Event:: model (timed callbacks).
We can sort out the "I"/"we" stuff later.
The following is one approach. We can rewrite it or rework it. I just had to do something. You know how it goes =)
My writing style is casual and ranty and perhaps conversational (and perhaps confrontational). I'm sure there's good and bad in that, which means room for optimization.
Introduction to Continuation-Based Web Applications
For those who haven't heard of continuation-based web applications, here is a poem for you to ponder:
Web applications are stopped and then restarted between every single user interaction.
cgi applications
rise from ash then burn again
upon each request
Imagine, if you will, writing a desktop application that had to completely exit and start from the beginning with each click of the mouse, each completion of a dialog box. To overcome this strange situation, the first thing your program would have to do is figure out what it should be doing (in the most likely case that it is in the middle of something) and pick up where it left off. There are two things that must be remembered between requests -- data state and control flow state.
Data state is pretty easy to take care of. Before you exit you stash all the data somewhere, in a file say, and give the user a secret number or a cookie. When they come back, so long as they haven't eaten their delicious cookie, they give it back and you figure out which data is theirs. This is fairly straightforward.
Control flow state, however, is a can of worms. Sometimes the user input itself will indicate what place in the application the user is at.
Ways to deal:
AJAX - put the state machine in Javascript
Mode passing parameter and a switch statement at the top
Each form as a separate app and URL (often seen in PHP)
URL as object method (rails)
Continuations to invert control flow
There is a fundamental difference between the way you structure web applications and the way you compose desktop or command-line applications. I'm not speaking of model-view-controller or other overall architecture, but rather at a much lower level.
------------------
--------------------------------------------
Continuations are awesome. Mention Seaside. Perhaps get a dig in on fake continuations (they call them "Delimited Continuations" but even this is not true IMO) in Jifty.
Continuations are not perfect. Especailly since they're really co-routines (even I lie when I say that I have continuations). Memory overhead, non-core feature.
Continuations are fantastic. Event:: model (timed callbacks).
We can sort out the "I"/"we" stuff later.
The following is one approach. We can rewrite it or rework it. I just had to do something. You know how it goes =)
My writing style is casual and ranty and perhaps conversational (and perhaps confrontational). I'm sure there's good and bad in that, which means room for optimization.
Introduction to Continuation-Based Web Applications
For those who haven't heard of continuation-based web applications, here is a poem for you to ponder:
Web applications are stopped and then restarted between every single user interaction.
cgi applications
rise from ash then burn again
upon each request
Imagine, if you will, writing a desktop application that had to completely exit and start from the beginning with each click of the mouse, each completion of a dialog box. To overcome this strange situation, the first thing your program would have to do is figure out what it should be doing (in the most likely case that it is in the middle of something) and pick up where it left off. There are two things that must be remembered between requests -- data state and control flow state.
Data state is pretty easy to take care of. Before you exit you stash all the data somewhere, in a file say, and give the user a secret number or a cookie. When they come back, so long as they haven't eaten their delicious cookie, they give it back and you figure out which data is theirs. This is fairly straightforward.
Control flow state, however, is a can of worms. Sometimes the user input itself will indicate what place in the application the user is at.
Ways to deal:
AJAX - put the state machine in Javascript
Mode passing parameter and a switch statement at the top
Each form as a separate app and URL (often seen in PHP)
URL as object method (rails)
Continuations to invert control flow
There is a fundamental difference between the way you structure web applications and the way you compose desktop or command-line applications. I'm not speaking of model-view-controller or other overall architecture, but rather at a much lower level.
------------------