Steven Noels wrote: >>Sounds good to me. Just another small note: I'm not *that* sure about >>focusing on the "content-centric" concept. I do believe that Cocoon is >>not just for content but can be seen as a generic and very powerful XML >>processing environment. We have XSP, we have SOAP, we have actions and >>we will have flowmaps: are we sure that we want to "sell" Cocoon once >>again mainly as a presentation engine for content-oriented sites? I'm >>afraid that people looking at the freshmeat blurb might look at it and >>just say "oh, ok, this is yet another XSLT tool"... > > that's exactly the nerves I wanted to touch :-) > > this is kind of blunt, but when reading up on Struts or WebWork, I immediately > understand where they are aiming at > > in the Cocoon dist as-is, there's samples of actions, of xsp, and other webapp > 'efforts', but none of them *documented* as being architected equivalent to Struts & > WebWork-like frameworks
I agree, and this is why I'm suggesting a "neutral" approach: Cocoon can be used already for interactive applications, and we want this to be even more true in the future. By saying "content-centric" we are somehow limiting the possible future scope of Cocoon (Struts user will never take a look at Cocoon because it has a label stating "content" on it). You're right: it would be somehow misleading now to promote Cocoon as an interactive application builder, since we're not there yet, so what I'm suggesting is to omit any label as of now. This neutral approach might pay off in the future. Enough marketing stuff for today :)Ciao, -- Gianugo Rabellino --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
