[OT] aren't u approaching the threshold of overcomplexity?

[Ar...@Techspan.com]

Recently I realized that I can't understand significant percentage of
posts in cocoon-dev. I've no clue what are they about. 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] aren't u approaching the threshold of overcomplexity?

[Stefano Mazzocchi <st...@apache.org>]

Argyn.Kuketayev@Techspan.com wrote:
 > Recently I realized that I can't understand significant percentage of
 > posts in cocoon-dev. I've no clue what are they about.

Thanks for starting this thread, I would have started a similar one
myself over the weekend, but since we are here, let me give you my
perspective.

Cocoon is admittedly a complex beast and has been stretching the limit
of many technologies since it started and even come up with our own when
none existed.

Is it getting 'too complex'?

I would say no, but I admit it's becoming 'too complex too fast'.

I don't think there is a threshold of overcomplexity by itself, but for
sure there is a limited number of complexity that users can digest over
a given time period.

Now: what can we do for this?

One solution would be to slow down complexity growth, but this is very
hard to do in practice for an active, diverse, talented and numerous
community like ours (which many other projects envy us, BTW)

A proposal could be to tight voting rules on adding new features: moving
from lazy consensus to majority. But I've never seen it done before and
I have the feeling it might stop innovation.

Another (totally different) solution is to limit the scope of Cocoon
itself. Or, at least, the scope users perceive.

This is why I want blocks so badly.

What you are perceiving is, IMO, a reflection of the fact that Cocoon is
extremely modular internally (thus allows extremely parallel development
in its core) but it's extremely monolithic externally (thus making it
seem like one huge big thing to users)

Add the fact that rather of development is still faster than rate of
documentation and we reach this point.

Think about Java for a second: the entire Java platform is *huge* and
probably no single person in the world knows it all. But few have the
perception they are approaching a threshold of overcomplexity since
things are well isolated.

Another problem is that, internally, things are already well isolated
and componentized. (Even too much, for my own personal taste, but that's
another story) So developers that know well the cocoon internals, don't
perceive the 'clockwork syndrome' that users perceive when they install
a monster WAR file of 18Mb!

At the same time, let me tell you that this list is called 'cocoon-dev'
because it's where cocoon developers meet, work and, rare as it is in
OSS, design.

Cocoon is one of the few web technologies that is actually breaking new
ground. This requires design and design requires boring discussions like

   {1.1} is better than {[1]1}

even if it takes 150 email messages to understand *WHY* some people is
discussing about these apparently stupid things.

I could point you to the thread where we discussed the names of the
pipeline components. It took us months to agree on the 'now carved in
stone' generator/transformer/serializer triad.

And yes, it would be apprently stupid that in order to choose if one
variable expansion automatically fallsback or not, we take serveral
*hundred* email messages, while bigger features like 'adding ability to
serialize into flash' get apparently very little attention.

But instead of the proverbial Perl's "there is more than one way of
doing it", we try to implement on architectural design Pascal's famous
sentence: "I write you this long letter because I lack the time of
making it shorter".

We would like to spend the time *here* on this list to make sure
everything is as shorter and less overlapping/confusing as possible,
than leaving the users to do that.

Some say this is a rather ivory-tower-like way of thinking, but since we
are very open to suggestions (and the rate of committer's exchange
proves that without doubt) things are balanced out.

So, to let's summarize a little (I did lack the time to make this email
shorter :)

1) Cocoon's development is healthy and very active. I would not try to
limit this because I think it's a great value. Probably the greatest.

2) Cocoon needs to reduce its external monolithicity. Blocks will
hopefully reduce that to a great extend on Cocoon 2.2 (we don't want
blocks to showstop 2.1)

3) Cocoon tries to help users by brainstorming a lot during development.
This makes development and design hard to follow. But people are
encouradge to ask for summaries or reviews when discussions get out of
hand (this happened recently with the InputModule discussion)

Hope this helps.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org