cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Continuation-enabled Rhino status (was: Re: [vote] Starting 2.1-dev)
Date Thu, 11 Apr 2002 11:59:46 GMT
Ovidiu Predescu wrote:

>On Wed, 10 Apr 2002 11:30:11 -0800, Rob Jellinghaus <> wrote:
>>At 10:29 AM 4/10/2002 -0700, Ovidiu Predescu wrote:
>>>Rhino has two ways of running JavaScript scripts. The first one is
>>>translating the script in a structure of internal objects, which are
>>>then "executed". The second approach, a lot faster that the first one,
>>>translates the JavaScript scripts in internal Java classes, which are
>>>compiled to bytecodes on-the-fly and executed as normal Java code.
>>>Adding support for continuations in the compiler mode is not possible,
>>>due to the impossibility to manipulate the Java stack frame.
>>This places a lower bound on the speed of any continuation-based Cocoon web 
>>I would steer clear of using a non-compilable technology in any 
>>sufficiently large-scale web site.  Hence, this ower bound on the flow 
>>engine's speed may imply an upper bound on the scale of Cocoon deployments 
>>using the continuation-based flow engine.
>>It is also curious how this performance constraint is so at odds with 
>>Cocoon's general predilection to compile everything whenever possible, for 
>>maximum throughput.
>>It pains me to say all this, as I think continuations are elegant as hell 
>>and Ovidiu's work seems quite impressive, but I do not believe that 
>>continuations will become efficiently implementable in the JVM (or in 
>>JVM-based languages) anytime in the next few years.  Hence, I do not think 
>>that continuations should become the main focus of Cocoon's flow support, 
>>if Cocoon has scalability as a primary design goal.
>I don't see why we should stay away from non-compilable technology.
>Perl, Python, PHP and lots of other interpreted languages out there
>are successfully used to drive very large Web sites. None of them
>compiles anything to C, they all interpret the scripts that describe
>the Web application.
>Some of these Web applications have tens of thousands of lines of
>code, all interpreted. I haven't noticed any problem accessing sites
>like Slashdot (Perl), Yahoo Maps! (Python), Yahoo Store! (Common
>Lisp), and many others.
>We don't need to have continuations in the JVM to make use of
>them. Rhino JavaScript is quite fast as an interpreter even in
>interpreted mode. And remember, we use it only to drive the flow of
>pages, not to implement the whole application in it (although it is
>definitely possible to do it). If used carefully the continuations
>based approach to flow control should not add any noticeable overhead
>to an application.

Agree. Rhino shouldn't be used to write the whole app, but only as a 
continuation-enabled glue between the various business logic components 
written in Java.

Also (Ovidiu, tell me if I'm wrong), Java-written business logic can 
return objects that are held in flow script variables, and thus benefit 
from the continuations mechanism. So both worlds are complementary : the 
intrepreted flow script provides continuation support to compiled Java 
business logic.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message