On Mon, May 4, 2009 at 6:24 PM, Greg Ewing
John Graham 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?
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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
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.