cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] polymorphism and hotswapping
Date Wed, 14 Apr 2004 09:55:17 GMT
Leo Sutic wrote:

>>From: Stefano Mazzocchi [] 
>>first of all, I apologize if I sounded somewhat harsh at time in the 
>>past two weeks. It's been a hell of a time, 8 hour-long meeting in 
>>highly political places (semantic web + jcp) and, boy, I didn't have 
>>enough time between things to realize that here I was *not* 
>>constantly under attack.
>Mate, I'm from Avalon.
>I have scar tissue ten meters deep, so I don't feel that much.
>>      Do we really need hotswappability?
>Personally I have no need for it. The code is complex, and I am always
>a bit suspicious of relying on complex code. I also don't need to keep
>each individual server running all the time (can take them out of line
>one by one).
>However, would hotswap be useful during development of blocks? I know
>that many Cocoon developers (and webapp developers) like the ability 
>to just hit "reload my app" when the make modifications. 
>I also like the fact that stylesheets are reloaded when they change 
>on disk, so I can make a stylesheet change, hit F5 to reload the page,
>and see my change.
>If I am going to store skins and resources inside blocks, I would
>like to be able to change them without restarting Cocoon.
>>      Is it worth the price to pay for the complexity?
>The question is if we need to design for hotswap and/or implement it.
>I would like us to use the design work Pier has put into the new 
>kernel, and make sure that the Cocoon core interfaces *support* 
>hotswap. That is, if we later on wanted to add hotswap, we should be
>able to do so without changing the Cocoon core interfaces. I 
>think we can come up with a client interface that's very easy to
>use and addresses the objections to the current interface (i.e. too
>ugly client code, too much responsibility on the client, etc.)
>But I don't think we have to *implement* hotswap at this moment.
>At least not all of it.
>The important part is to get blocks running. Hotswap of blocks is
>of lower priority, and I don't want the 2.2 to be stuck in development
>because hotswap is so hard to implement correctly. Get the blocks
>running, and then we can start thinking about how to get hotswap
>Finally, when we decide to allow hotswap, I want us to start off
>by realizing that we will only cover some cases when hotswap is
>possible. There will always be the pathological case where hotswapping
>simply isn't posible. But if we can say: "Hotswapping is possible under 
>the following three conditions: (1) ... (2) ... (3) ...", then at least
>we will have hotswap - probably for 90% of the cases - and I think
>the complexity will be manageable.

Jumping in late on this...

I totally resonate with Leo's excellent opinion. Let's make h13y (thanks 
Bertrand!) possible, but let's not make it a top priority that will 
badly delay 2.2 development.

IMO, h13y doesn't have so much impact on the client code. It's not like 
with RMI where every method call can throw a RemoteException because the 
remote peer has disappeared. 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 

So let's move on with hotswap-capable interfaces, and tackle problems 
one at a time.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message