From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]
Leo Sutic <[EMAIL PROTECTED]> writes:
<big snip/>
My whole argument is that your design will end up being very very
complicated and very very hard to develop for, since it provides so few guarantees to block developers. Things like "what code is running", for
example.
So if you've got something for which blocks are not suited (like perhaps SSL, or a DB pool), don't use blocks; use modules or whatever it is that does give you the contract you want. The rest of Cocoon isn't going away...
I thought Blocks would be the new, well, building blocks of cocoon. As Stefano said here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108014494301217&w=2 What does this mean for you?
Well, it's rather simple: old code will work in an avalon sandbox.
It basically means that it will see cocoon *exactly* as it used to be
before.
But this will also mean that will be isolated from other blocks and
will not be able, for example, to load components from other blocks.
So, the rest of Cocoon isn't going away, but it isn't going anywhere else either.
I didn't say that cocoon wouldn't rewrite avalon stuff to suit our needs *and* provide old avalon stuff to suit the legacy needs.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
