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 portal.apache.org 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 us.

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 sitemap?

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.

--
Stefano.



Reply via email to