cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: [Kernel2.2] Comments
Date Wed, 31 Mar 2004 19:41:25 GMT
Leo Sutic <leo.sutic@inspireinfrastructure.com] writes:

> > From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
> > 
> > Leo Sutic <leo.sutic@inspireinfrastructure.com> 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.

Well, no, I don't think so:  the above does tell you that in order to
use blocks you have to use blocks (and not for example, Avalon
components).  It doesn't say that blocks are the only way to do
things...

Other parts of Cocoon will continue to change and evolve.  There has
also been discussion on how that happens, and the generalized concept of
replaceable components that are not blocks AFAIK remains.  




Mime
View raw message