Return-Path: 
 <cocoon-dev-return-44327-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 38462 invoked by uid 500); 1 Jul 2003 15:32:11 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 38413 invoked from network); 1 Jul 2003 15:32:10 -0000
Received: from unknown (HELO trinity.anyware-tech.com) (217.112.237.100)
  by daedalus.apache.org with SMTP; 1 Jul 2003 15:32:10 -0000
Received: (qmail 24529 invoked from network); 1 Jul 2003 15:35:14 -0000
Received: from unknown (HELO anyware-tech.com) (10.1.0.254)
  by trinity.anyware-tech.com with SMTP; 1 Jul 2003 15:35:14 -0000
Message-ID: <3F01A979.4040302@anyware-tech.com>
Date: Tue, 01 Jul 2003 17:32:09 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
X-Accept-Language: fr, 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>
In-Reply-To: <3F012458.23964.985965F@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Upayavira wrote:

>On 30 Jun 2003 at 22:29, Sylvain Wallez wrote:
>
>  
>
<snip/>

>>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),
>

We already have this with the ThreadSafe marker interface. So yes, we 
could have transparent release/lookup for ThreadSafe components.

>and maybe a FlowSerializable interface (has a way that the state can be stored into the continuation and then restored, all transparently?
>

Good point. But actually, this is not related exclusively to flow, but 
to the ability to externalize the component state. So this could be :
interface StateExternalizable {
  Object /* or Serializable? */ getState();
  void setState(Object state);
}

>So you would have to consciously code your components to use either of these interfaces, otherwise you'll have to manually release them before creating a continuation.
>

Yep. An you would still get an error if there are some unreleased 
components that are neither ThreadSafe nor StateExternalizable.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com