Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <407D115C.2090700@apache.org>
Date: Wed, 14 Apr 2004 12:24:28 +0200
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] polymorphism and hotswapping
References: <00f601c41e71$04355bc0$0801a8c0@lagrange>
 <407D0A85.4080508@apache.org>
 <B97C045E-8DFC-11D8-8056-000A95AF004E@codeconsult.ch>
In-Reply-To: <B97C045E-8DFC-11D8-8056-000A95AF004E@codeconsult.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Bertrand Delacretaz wrote:

> Le 14 avr. 04, � 11:55, Sylvain Wallez a �crit :
>
>> ...Blocks are running inside the same VM and although a wiring can 
>> switch, it cannot suddenly disappear. And we can find a lot of 
>> strategies to make this transparent to client code (including my idea 
>> of deferring actual switch which strangely had no feedback)....
>
>
> Deferring, does that mean keeping the "old" block around as long as 
> it's in use, while the "new" block is used by clients that have 
> recently started using it?


Exactly! This solves most (if not all) problems related to statefull 
components, since the user would be guaranteed to use the same component 
between lookup and release [1].

> If yes, this is (AFAIK) exactly what unix/linux has been doing for 
> ages with executables:  you can replace an executable that is already 
> running, and processes which are already running keep using the old 
> version.
>
> It works very well combined with "kill" to cleanup old processes and 
> restart them with the new version, so maybe in the case of blocks some 
> kind of "kill" and "ps" equivalents would be needed to make this work 
> well.


Very good comparison, as I suggested their should be a means to force 
old blocks to garbage if ever some client code "forgets" to release them 
[2].

Sylvain

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108033164725441&w=2
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108143449906750&w=2

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