cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Goal of the Cocoon TLP
Date Thu, 05 Feb 2004 13:48:29 GMT

On 5 Feb 2004, at 06:46, Geoff Howard wrote:

> Steven Noels wrote:
>> On 05 Feb 2004, at 12:10, Carsten Ziegeler wrote:
>>>> We should be able to describe what we do in a more
>>>> generic sense. Look at the recent logging/portal TLP efforts. I've 
>>>> even
>>>> been daydreaming whether the Cocoon portal shouldn't 
>>>> cross-liaise/find
>>>> common grounds with the new portal TLP, but that's irrelevant to 
>>>> this
>>>> discussion.
>>> Although it's irrelevant here, I wanted to propose to move the cocoon
>>> portal to the portal TLP as soon as the portal TLP is more concrete.
>> Cool - like that!
>>>> So, it's up to all of us to choose the correct categories. Good.
>> Yep - other suggestions?
> Would there be benefit to keeping it more general: "XML based 
> application and publishing framework and applications built on and in 
> support of that framework".

Glad to see this moving forward. Thanks, Steven.

I agree with Carsten that moving Cocoon Portal to the future makes perfect sense. I would suggest coming up with a 
name for it (Cocoon Portal is good as long as you keep it inside) 
[please no acroynims, not even recursive ones ;-)]

As for the charter, I agree with Goeff here: we need to keep it general 
or we would need the board to change our charter every day.

So, I would:

  1) keep it language neutral: many people dislike java, but they can 
leave with it if th application is worth the effort (think lisp and 
emacs, for example)

  2) keep it technology neutral (don't say XML/XSLT/SAX/DOM)

  3) aim to identify the achitectural principles (modularity, 
composability, separation of concerns, feature reductionism)

I know that we can always has the board to change the charter, and, to 
be honest, they don't care much as long as the community behaves well 
and cocoon has been a champion on that so they are very easy going with 

But the technological landscape might change dramattically in the 
future. We might substitute Java for another langauge if Microsoft buys 
Sun and kills it. We might move from SAX to something else. We might 
declare XSLT too complex. Who knows! Think about flowscript: would you 
have thought that javascript would be there side by side with the 

Let's not limit ourselves to the technology, that's just an instrument 
and moves along with time (and we should *not* be willing to avoid 
trying out new technological directions)

On the other hand, Cocoon *does* have an identity and it's because of 
its design principles:

  1) composability instead of programmability

  2) enforcing separation of concerns

  3) minimizing overseparation of concerns

  4) less is more, but no less than what you need

I'm perfectly aware of the fact that these might be so broad that the 
board might not be happy with it, so I'm willing to get some tradeoffs 
and put some names and technology so that we can nail it down on where 
we are today, but these are my thoughts.


View raw message