Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 11296 invoked by uid 500); 11 Sep 2002 14:47:24 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 11277 invoked from network); 11 Sep 2002 14:47:24 -0000 Message-ID: <3D7F57CA.50209@anyware-tech.com> Date: Wed, 11 Sep 2002 16:48:42 +0200 From: Sylvain Wallez Reply-To: cocoon-dev@xml.apache.org Organization: Anyware Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fr, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org CC: Tim Coninx Subject: Re: Brakes (was: [control flow] changes and new sample) References: <20020911114835.GD11167@mauryl.cs.kuleuven.ac.be> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Tim Coninx wrote: >Hello, > >As I was pointed by a friend to the previous thread, I noticed a >proposal to prototype Brakes, which I have been working on a time ago. > >This is not a commercial message, but a status report of the technology. > >Brakes consists of two parts: >- A bytecode transformer adds bytecode after every method start, > and before every method call. > The bytecode before each method call makes sure the control flow of > the executing thread gets saved. > The bytecode at the start of each method checks the state of the > thread, and acts upon that (normal/saving/restoring) >- A small experimental framework which serves as a starting point for a > thread, a place in which the control flow gets saved, and the point > from which the control flow gets restored. > >The research on brakes is being discontinued, partly because too few >people worked on it, partly because we (I) didn't had the nerve to get >this project into a more serious prototype stage. > >The code however exists, and is usuable to certain extent. > >The biggest problem is the bytecode transformer. This is a huge piece of >work by Bert Robben, a member of our research group who left four years >ago. We suspect he is the only one with full understanding about the >transformer. >A positive thing is that the transformer is based on BCEL (the bytecode >engineering library) by Markus Dahm. (During that time named JavaClass). >BCEL is still under development, now under the wings of Jakarta > http://jakarta.apache.org/bcel/ > >I am pretty sure that much of the 'difficult' functionality in the >transformer is now handled within the BCEL. So a rewrite of the >transformer /should/ be feasible. > > Agree. I'm also using BCEL for class transformation, and I must say it makes things relatively easy... once you master the virtual machine specification ! >The framework part is of course something that should be redesigned to >fit on Cocoon. > >The past weeks, I have been looking again at BCEL, and have been >gathering ideas about how to redesign the bytecode transformer. When >you are serious about using Brakes in Cocoon, I am of course willing >to devote a great deal of time in helping with the transformer and the >framework's integration in Cocoon. > We are *very serious* at using something like Brakes in Cocoon. The use case is however a little bit different than Brakes : we want to implement continuations, which are the capability for a program to interrupt itself and be resume later in the state where it was interrupted. The main difference (as far as I understand) with Brakes is that program interruption is not triggered externally in our case. >About licensing: because Brakes was abandoned so early, it is covered >under the same proprietary license as it's parent project, Correlate > http://www.cs.kuleuven.ac.be/~distrinet/projects/CORRELATE/ > >However, (again when you are serious about using brakes into Cocoon) it >will be possible to decouple Brakes from Correlate and embed the >subproject (Brakes) into Cocoon, or at least release it seperately under >the APL. > We would be *very interested* in that. Is some license change possible so that we can at least look at the source code ? >Oh, I am new to this list, so forgive me if I broke some rules. > No problem. This was perfect. Welcome ! Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:sylvain@apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org