Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <402267C0.4080700@nada.kth.se>
Date: Thu, 05 Feb 2004 16:56:48 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.6b) Gecko/20031208
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Goal of the Cocoon TLP
References: <LKENJPKDAIKAPKHEOCMMGEPIHIAA.cziegeler@s-und-n.de>
 <3C9CD5B7-57CC-11D8-91BC-000A958B684A@outerthought.org>
 <40222D33.1040800@leverageweb.com>
 <FAAA29D3-57E1-11D8-B395-000393D2CB02@apache.org>
In-Reply-To: <FAAA29D3-57E1-11D8-B395-000393D2CB02@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:

<snip/>
> 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)
> 

To me this sound like FS on the mission statement level. I think we have 
a strong consensus in keeping the main API:s in Cocoon as stable as 
possible to protect our own and our users investments. And I guess also 
because strong contracts actually is a requirement for making parallell 
inovation possible. If the technolgical foundation can change at any 
moment it is nearly impossible to build new layers above it.

If we change from Java to some other programing language I think that 
changing our mission statement will be one of the smallest problem. 
Likewise for replacing XML with something else. Although it in some 
sense would be much cooler to base pipelines on a pull based protocoll, 
leaving SAX would make all the current generators, transformers, 
serializers as well as many other components obsolete.

IMHO we allready have some kind of "de facto", partly implicit mission 
statement. Even if we don't agree about everything in Cocoon we agree 
about quite a lot. I think we also share, at least to a large part, a 
common vision about what Cocoon is and what it should become. We have a 
strong project culture in Cocoon as well. I gueuss you have to accept a 
rather large personal responsibillity for this situation ;)

I think we have much more to win than to lose in making this common 
ground explicit. Booth for explaining for the rest of the world what 
Cocoon is about and for our own focus.

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

These are things that have time spans of several years from early ideas 
to full technical support and community acceptance. We can change or add 
to our mission statement in such cases.

> 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) 

Of course we should continue to innovate, (I would lose my interest in 
Cocoon if we stop ;) ), but if we look at our history we can see that it 
takes a long time before an idea becomes a part of the core techinchal 
identity of Cocoon.

> 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.

I think Cocoon has a quite strong technical identity as well, why not 
describe that also. I think Stevens list is a good starting point. The 
first few paragraphs in "what is Cocoon?" in the Cocoon documentation 
could also be part of our mission statement.

Although I don't know anything about the board, our relation to it and 
possible "political" implications, I think that a mission statement can 
be something more than "something we state because the board requires 
it", it is a statement addressed to the world and to ourselves about 
what Cocoon is about.

You have never seemed afraid of stateing strong opinions about technical 
matters and visions, why this sudden shyness in this particular case? ;)

/Daniel