On Thu, 11 Apr 2002 13:59:46 +0200, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
> Ovidiu Predescu wrote: > > >On Wed, 10 Apr 2002 11:30:11 -0800, Rob Jellinghaus <[EMAIL PROTECTED]> 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 > >>application. > >> > >>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. Yes, this is correct. And you can hold these Java objects in a variable across multiple pages. This is effectively a much better approach to using session objects. In fact with the flow language in place, you no longer need session objects, they are completely obsoleted by variables in the flow language. In the sample I posted last night in response to Ivelin's message, the 'hasCar' is one such variable. In the calculator example in Schecoon, the 'a' and 'b' variables have a similar role. Of course, you can have variables that hold anything you want, but be careful since they get saved in continuations, thus increasing their size. This is potentially dangerous for long lived transactions, as the size of the JVM will increase. For now the only way to avoid this problem is to set the variable to null, as soon as you no longer need it. In future I plan to work on the Rhino JavaScript engine to do two things: - detect temporary variables and automatically set them to null after their last usage. This will avoid temporary variables to be stored in continuations, thus reducing the size of a continuation. It will relieve the programmer from having to assign null to such variables. - augment variables that hold transient values. For example, a database connection pool object should not saved in a continuation, but instead released back in the pool right before the continuation is saved, and obtained back right after the continuation is resumed. Regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
