cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] On building on stone
Date Thu, 25 Mar 2004 18:25:24 GMT
Leo Sutic wrote:

>>From: Stefano Mazzocchi [] 
>>>Is this related to the statefulness of the component?
>>... as you correctly spot, the thing is way more tricky than 
>>it looks at 
>>The way we solved this was to enable a sort of loose-coupling wiring 
>>between components. This requires block A to check for the 
>>wire validity everytime a service is invoqued and, if not, look it up
> again 
>>(obviously the framework will provide helping code for this).
> Could also be solved by introducing the notion of component
> transactions.
> Add a read and write lock to each component wire.
> Block A could in effect disable hot-swapping of a component while it is
> used (i.e. get a read-lock on the wire), while the hot-swap machinery
> tries to get a write-lock on the wire. Thus, the component will
> never be swapped when used, and thus the wire-check is unneccessary.

See why I want to have our own kernel? to attract new ideas!

Leo, if you have new ideas bring, them on. Just like we did for Woody 
that later became Cocoon Forms (CForms) we are going to use Tani (Pier's 
container implementation) to seed the Cocoon Kernel (CKernel).

It might be without modifications or it might be completely rewritten.

We *DO*NOT* care!

It's not an ego fight, it's not my ideas are better then yours, it's not 
we are going to conquer the world and show how smart we are....

.. the goal is to create a solid foundation for cocoon so that it can 
grow in the next generations and allow much more complex web 
applications to be built.

The more ideas, the merrier.

As for your specific solution, well, I think it's better to start with 
what Pier has, then, once the code is in our CVS, we'll discuss how to 
improve it/change it/throw it away.

How's that as a deal?


View raw message