Pier Fumagalli <[EMAIL PROTECTED]> writes: > > On 31 Mar 2004, at 18:43, Hunsberger, Peter wrote: > > 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.
Yah, I saw your mention of that; that's partly why I included "possibly". Personally, I don't see the possibility, but if Leo thinks he does, well then, he's free to code up old style Cocoon code as far as I can see... > I'll need to come up with some block examples soon before being so > misunderstood! :-) Hmm, let me see, multi-version, indirect, proxied class loading. Do you really figure a couple of examples are going to stop you from being misunderstood? ;-)
