Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 45016 invoked by uid 500); 1 Jul 2003 17:12:19 -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 45003 invoked from network); 1 Jul 2003 17:12:19 -0000 Received: from pop017pub.verizon.net (HELO pop017.verizon.net) (206.46.170.210) by daedalus.apache.org with SMTP; 1 Jul 2003 17:12:19 -0000 Received: from verizon.net ([4.40.112.123]) by pop017.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030701171222.JZDS27254.pop017.verizon.net@verizon.net> for ; Tue, 1 Jul 2003 12:12:22 -0500 Message-ID: <3F01C1F7.2040801@verizon.net> Date: Tue, 01 Jul 2003 10:16:39 -0700 From: Christopher Oliver User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: More on FOM References: <3F00682A.10801@apache.org> <3F012458.23964.985965F@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop017.verizon.net from [4.40.112.123] at Tue, 1 Jul 2003 12:12:19 -0500 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Upayavira wrote: >On 30 Jun 2003 at 22:29, Sylvain Wallez wrote: > >... > > > >>>>I suggested that components being heavyweight resource, allowing >>>>them to cross continuation boundaries should be prohibited. >>>>Automatic release doesn't seem a good solution to me, as it would >>>>mean that script variables would hold released components, thus >>>>leading to unpredictable behaviour (think about stateful pooled >>>>components). So my opinion is to raise an error if there are some >>>>unreleased components when a continuation is created. This will >>>>allow users to quickly learn the safe practices related to >>>>component management in flow scripts. >>>> >>>> > >I tend to agree. > >... > > > >>Once again, I agree that explicit release is very unnatural. But >>automagic release is good only if we can have some automagic restore. >>For this we can have getComponent() actually return a proxy to the >>real component, and have the proxy do a release/lookup when a >>continuation is suspended/reactivated. But as elegant this may seem, >>this won't work : stateful components have... a state, and a >>release/lookup cycle destroys this state. >> >>So I don't see any other solution... >> >> > >How about defining a FlowSafe interface (contains no state and can be >released/looked up transparently), and maybe a FlowSerializable interface (has a way >that the state can be stored into the continuation and then restored, all transparently? > > > Continuations do not serialize state. Continuations restore the program counter and cause you to retain references to function invocations and local variables, however they do not "roll back" the values of those variables.