Re:Seaside 3.0 released
by johnwatson11218 on Sunday September 12, 2010 @09:05PM
(#1685084)
yea I hear you. The problem I have will passing the http parameters is that it only goes one level deep. If you want to nest it arbitrarily you would have to build up a comma separated list of values to refer to all the places you need to return to. At that point, if you think of this list of return places as a set of pointers it is as if you are implementing a stack. Having this kind of thing as a first class construct could maybe allow this to be checked by the compiler.
To be honest the details of implementing 'scalable multi-threaded continuations' is beyond my skill level.
Yes scaling continuations based web apps can be a big headache. I think this is why the Seaside developers have been scaling back continuations and making them optional in the framework: http://lists.squeakfoundation.org/pipermail/seaside/2007-Dec...
Coroutines are an interesting lighter alternative (though will still suffer from threading & session affinity issues).
See coro based libraries/frameworks influenced by Seaside like Continuity (http://continuity.tlt42.org/) & Nagare (http://www.nagare.org/) (which I think uses coros?).
Here is a fulling working Continuity example:
use strict;
use warnings;
use Continuity;
use HTML::AsSubs;
Continuity->new->loop;
sub main {
my $r = shift;
###########################################
# helpers
my $update_billing_info = sub {
return 1 if eval { $r->param('updated') };
return;
};
my $display_update_billing_info = sub {
$r->print(
form(
input( {type => 'checkbox', name => 'updated'}, 'updated?' ),
br,
input( {type => 'submit'} ),
p( "No. of tries thus far - $_[0]" ),
)->as_HTML
);
};
my $render_checkout_screen = sub {$r->print("Updated after $_[0] submits!")};
###########################################
# business logic
my $count_tries;
while (not $update_billing_info->()) {
$display_update_billing_info->( $count_tries++ );
$r->next;
}
$render_checkout_screen->( $count_tries );
}
Having used a few frameworks, I can tell you it's also easier to debug code that's closer to http requests. Being able to simply look at what's being passed in a simple way and understand everything instantaneously is a big advantage. Actually, this argument is more about the tools at hand, but there are definitively more and better tools to analyze http requests than anything else.