Leo Sutic wrote:


From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]

But...


Is this related to the statefulness of the component?

... as you correctly spot, the thing is way more tricky than it looks at first.

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?

--
Stefano.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to