Re: [Python-ideas] A Continuations Compromise in Python
One use case in the back of my mind dealing with the Actor model was with the web. Actor's communicate via message passing only, and in many cases this is asynchronous message passing. This is basically the same thing as sending and receiving information via HTTP. Although I admit I haven't done much web work in awhile... I think the Seaside framework uses continuations in this way. Anyway, when a user is navigating a website, if they have a few forms to fill in, it can possibly become hair keeping track of that user's session. I'd imagine the standard way is whenever the user inserts information into a form and transfers to another page in the site, some sort of session object or state object is updated with this information, and any further interactions with them are tracked this way. This can cause problems when they use their back button, or just copy the web address to open a new tab (perhaps to navigate to a different part of the site.) Message passing/continuation passing style, in this case, would basically - as I understand it - code up each specific page as an island, expecting all user information to be given in its arguments and not making any look ups to any sort of session or state object for the user. Jumping to a new web page then is nothing more than 'continue' to another function call, whilst passing all needed and gathered information through function arguments alone. The backbutton and clones work in a simpler fashion because there is no more persistent state between page visits, all state is transferred at the boundary right where the 'continue' happens. Like many have mentioned, you can probably do the same thing, once again by having some sort of trampoline outside of each page handler figuring out where to send the use next, and transferring some sort of global state id along with each user, I just imagine that since web programming is one of the major uses of Python, this sort of thing has to get pretty tiring. I realize I'm still speaking a little too high level and in generalities, but if someone would like I could take some time and try and drive the above example into actual code. On Sun, May 3, 2009 at 5:13 PM, Mike Meyer <mwm@mired.org> wrote:
True, but similar to ABC's, if each of your major users (i.e. frameworks) ends up reinventing a incompatible wheel, when is it time to try and come up with some small standard they can all share? On Mon, May 4, 2009 at 6:53 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
John Graham wrote:
Maybe I'm missing something, but I don't see how a stateless web server would make use of any kind of continuation-invoking mechanism. The main loop of such a server just gets a request, maps the url to a function, and then calls that function with parameters from the query string. The function does its thing and returns some html to send back to the browser. It has no idea which function should be called next, because there's no "next" in a stateless server -- it depends entirely on what the user of the browser does from there. Another way of thinking about this is that the continuation is encoded in the html form that the function returns. So the main loop of the server, together with the browser+user, can be thought of as a kind of trampoline, where the "function" you return isn't a Python function at all, but a form whose "submit" button sends a query that results in the desired function being called. It seems to me that the existing Python language is perfectly adequate for expressing this. -- Greg
On Mon, May 4, 2009 at 6:24 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
I believe it would be used for state that is not transferred via the URL, such as a user's session with the server should some sort of persistence take place.
John Graham wrote:
In that case you have a stateful server rather than a stateless one. But I still don't see how the proposed "continue" statement would help, because you don't want to call the continuation *now*, you want to defer it until later. So you still need to store it somewhere or return it to a trampoline. Seems to me a better structure for this would be to represent the session by an instance of a class, with methods corresponding to the various queries that can be sent. Then you've got much the same situation as with the stateless server, except that the mapping from query string to function goes through an intermediates step of locating the appropriate session object, based on a session id in the query. Still no need for continuations anywhere. -- Greg
On Mon, May 4, 2009 at 8:11 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
In this case, continuation-passing-style would force capturing of this state in the same way many 'functional-style' languages capture state, immutable state in closures? I can see how immutable state from closures might have a benefit when back button and clone-tab buttons are pressed, since there is no one grand object or class to refer to per session, but more like little breadcrumbs of immutable state between function calls.
John Graham wrote:
Even if it is, I still don't see how the proposed TCO feature would help here, because it calls the supplied function *immediately*, which is not what you want to do. What you're talking about amounts to running the session as a coroutine, and what you want to do is suspend the coroutine until a particular query comes back from the browser. TCO won't help you with that. -- Greg
True, but similar to ABC's, if each of your major users (i.e. frameworks) ends up reinventing a incompatible wheel, when is it time to try and come up with some small standard they can all share? On Mon, May 4, 2009 at 6:53 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
John Graham wrote:
Maybe I'm missing something, but I don't see how a stateless web server would make use of any kind of continuation-invoking mechanism. The main loop of such a server just gets a request, maps the url to a function, and then calls that function with parameters from the query string. The function does its thing and returns some html to send back to the browser. It has no idea which function should be called next, because there's no "next" in a stateless server -- it depends entirely on what the user of the browser does from there. Another way of thinking about this is that the continuation is encoded in the html form that the function returns. So the main loop of the server, together with the browser+user, can be thought of as a kind of trampoline, where the "function" you return isn't a Python function at all, but a form whose "submit" button sends a query that results in the desired function being called. It seems to me that the existing Python language is perfectly adequate for expressing this. -- Greg
On Mon, May 4, 2009 at 6:24 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
I believe it would be used for state that is not transferred via the URL, such as a user's session with the server should some sort of persistence take place.
John Graham wrote:
In that case you have a stateful server rather than a stateless one. But I still don't see how the proposed "continue" statement would help, because you don't want to call the continuation *now*, you want to defer it until later. So you still need to store it somewhere or return it to a trampoline. Seems to me a better structure for this would be to represent the session by an instance of a class, with methods corresponding to the various queries that can be sent. Then you've got much the same situation as with the stateless server, except that the mapping from query string to function goes through an intermediates step of locating the appropriate session object, based on a session id in the query. Still no need for continuations anywhere. -- Greg
On Mon, May 4, 2009 at 8:11 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
In this case, continuation-passing-style would force capturing of this state in the same way many 'functional-style' languages capture state, immutable state in closures? I can see how immutable state from closures might have a benefit when back button and clone-tab buttons are pressed, since there is no one grand object or class to refer to per session, but more like little breadcrumbs of immutable state between function calls.
John Graham wrote:
Even if it is, I still don't see how the proposed TCO feature would help here, because it calls the supplied function *immediately*, which is not what you want to do. What you're talking about amounts to running the session as a coroutine, and what you want to do is suspend the coroutine until a particular query comes back from the browser. TCO won't help you with that. -- Greg
participants (3)
-
Antoine Pitrou -
Greg Ewing -
John Graham