cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Foster <jafos...@uwaterloo.ca>
Subject BSF and Continuations
Date Sun, 03 Mar 2002 02:53:56 GMT
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.

Jason Foster



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


Mime
View raw message