cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@metalanguage.com>
Subject Re: BSF and Continuations
Date Sun, 03 Mar 2002 17:53:05 GMT
Jason,

On Sat, 2 Mar 2002 21:53:56 -0500, Jason Foster <jafoster@uwaterloo.ca> wrote:

> This post may reveal that I haven't got much of a clue, but here goes...
> 
> -----
> 
> My premise is that it would be cool to allow any BSF language to be used 
> to develop a cocoon web application, and that the goal is to allow for 
> something like continuations.
> 
> BSF allows a script to call back into the Java environment.  This is 
> currently being used by the ScriptAction to manipulate the various objects 
> associated with a request.  If I understand properly, the thread that 
> called the BSF exec() function is used to send messages to the objects in 
> the Java environment.
> 
> This is useful because when the BSF script calls back into the Java 
> environment, that thread can be suspended.
> 
> So consider the following chain of events:
> 
> - a request for a web application comes in
> - the Controller maps the request to a particular script
> - the Controller creates a new WebappThread
> - a set of proxy objects is created and are made ThreadLocal to the new 
> WebappThread
>      - each proxy represents one of the request and response objects
> - the proxy objects are registered with the WebappThread BSF manager
> - the script is executed in the WebappThread
> 
> Let's use the (JavaScript) script that Stefano sent out earlier...
> 
> var a = getA();
> var b = getB();
> c = a + b;
> show(c);
> 
> And let's look at the first line...
> 
> var a = getA();
> 
> I'm going to create a JavaScript implementation for getA() as follows:
> 
> function getA()
> {
>    ResponseProxy.SendCocoonPipeline("RequestPageA.xml");
>    var clientResponse = RequestProxy.getRequestData();
>    // parse clientResponse and extract A
>    return A;
> }
> 
> So now the question is what happens in ResponseProxy?
> 
> The answer is that the WebappThread:
> 
>    - generates the pipeline
>    - sends the pipeline results to the client
>    - registers itself with Controller mentioned earlier with a particular ID
>    - puts itself to sleep.
> 
> When the user submits their response, with some encoded session ID or 
> similar...
> 
>    - the Controller looks for a thread that registered itself with this ID
>    - the Controller changes the ThreadLocal proxy objects to reference the 
> new request and response objects
>    - the Controller calls resume() on the script thread, which continues 
> happily along
> 
> Presto!  Any BSF-aware scripting language can now pretend to have really 
> basic continuations, thanks to the proxy objects and the ability to 
> suspended threads.
> 
> What I'm still trying to figure out is whether this would allow for the 
> other really cool aspect of continuations, which is the ability to "travel 
> back in time" when the user hits "back" and submits a different 
> continuation ID.  I don't this that this approach would allow this 
> functionality.  On the other hand, if the BSF framework allows, or can be 
> hacked to allow, a script engine to dump its state to an object, then we'd 
> be set.
> 
> -----
> 
> I don't know if this makes any sense, but it seems like the idea should 
> work.  Although I like the idea of creating a custom language to deal with 
> webapps, it strikes me that a solution that would let me use any BSF 
> language transparently would be pretty nice.
> 
> Comments (especially from any BSF gurus) greatly appreciated.

The big problem is that on the server side you have a thread *per
request* waiting for the client to submit back a request. This model
clearly does not scale!

As for the ability to go back in time when the user hits the back
button, this is not possible. Since there is no saved program state,
the computation in the thread cannot be reversed to a previous state.

Greetings,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message