Compare slide 5 from Geert's very nice Rife webcontinuations presentation (pdf) with Tony's excellent Getting Started with Cocoon Flow. Gee, I know that sample from somewhere. ;-)
Obviously, Geert prefers Java over JavaScript for coding web application flow. IIRC, he's using Brakes for capturing thread execution state. Cocoon uses a patched version of Rhino, a Java JavaScript interpreter for this.
Given Uwyn's (Geert's company) current commitment to Rife, there's no chance that Geert will ever drop his baby in favour of a larger community. Still, it feels somehow comforting to see the similarities between Rife's feature sheet (slide 3 of the same presentation) and Cocoon one's.
Web continuations have been receiving more blog space lately, also in Python land. However, people indicate concerns about server resource exhaustion when using in a high-traffic environment. Of course, one needs a continuations "janitor", just as one needs to clean out stale sessions in web applications. Nothing new here.
Update: Geert chimes in to explain he didn't go for Brakes, but made some stuff himself (see the comment section of this post). Sorry about my confusion. :-/
Hey Steven,
RIFE doesn't use brakes since portable thread migration is still quite a bit different than easy to use continuations in a web context. Since I had to start digging in Brakes itself (which then seemed to be a project on hold), I preferred to write the whole shabang myself using asm instead of bcel. This now also leads to nice additions on top of the trivial pause, such as call/answer (http://www.uwyn.com/blog/#highlight01) in a very similar fashion as what Seaside provides.
Btw, I'll soon have added support for continuations with Groovy in RIFE too. Imho that's a much nicer scripting language for java-minded people than Javascript.
The resource exhaustion problem is a valid point. You have to be aware of it and limit the local variable scope if that's relevant. Since RIFE only allows continuations in the entry method of the element, you can very easily offload complex logic to other methods and break up your code (which is a recommended programming practice anyway). This already helps reducing the local scope considerably.
A minor comment about this post and according to a mailinglist entry that came up during a web search (http://www.mail-archive.com/dev@cocoon.apache.org/msg12627.html): RIFE supports continuations in Java, in fact that's the main incentive. Since it modifies classes at bytecode level, it's not a whole lot of work to offer the same for Groovy and other bytecode-compiled languages. It also respects the debugging information and all debugger operations continue to work.