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...
Well, I'm actually using the framework to build two things for my employer: an XML repository backed up by a DataBase (connection pooling and JDBC connections flying all around) and a HTTP/HTTPS NIO based (possibly with ESI support) proxy server that we're going to use as a Cocoon-frontend.
I'll need to come up with some block examples soon before being so misunderstood! :-)
Pier
