>-----Original Message-----
>From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
>Sent: Montag, 14. Oktober 2002 14:13
>To: [EMAIL PROTECTED]
>Subject: Re: [OT] aren't u approaching the threshold of overcomplexity?
>
>
>[EMAIL PROTECTED] 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.
Being a Cocoon afficiondo since only 6 month, I'd say Cocoon can be
compared to the English language. Once you get the basic grammar and
odd vocabulary (i.e. understand that map:act means "if", map:call means
"goto", map:serialize means "return" etc) you can already form phrases
which make sense and are useful. Of course, you are still a long way
from being able to read Shakespeare, but you don't need to if you just
want to order a pizza.
>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.
I think one of the main problems for new users is that Cocoon has
too many knobs to turn. It't a great thing that the advanced user can
plug
in a different XML parser or XSL transformer, but the average user
does not care about that, as long as default provided by Cocoon works
for him and is reasonably efficient.
There is now a 600+ lines cocoon.xconf file containing mainly stuff
I don't want to change or wouldn't know how to change mixed with a
few bits I certainly need to change, for example <datasources>.
That is certainly something which needs to be disentangled.
Also things like CInclude vs. XInclude should be eradicated. I guess
every beginner wonders like me which one to use. Both are somewhat 80%
solutions. Can't we go for *one* 99% solution.
>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!
Maybe I don't understand what blocks are about. If the intention is
to chop Cocoon into pieces from which customized mini-Cocoons can be
built, I think it is a bad thing. The size of the WAR file never
scared me. Any real-life Cocoon site we sooner or later employ SVG and
FOP and thus already need more than half of the JAR filesize.
We should not turn the Cocoon build process into an American sandwich
bar
where one was to pass Spanish Inquisition in order to get a sandwich.
Let's have just one Cocoon where people use what they need by just
naming
it in the sitemap. I don't fancy having to rebuild Cocoon everytime I
need an additional block.
Moving around existing Cocoon components, for example SVGSerializer into
blocks/batik, breaks the (very useful) unique package name to source
file
path relationship. It also looses the CVS history and makes
back-patching
old release versions more difficult.
>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.
Absolutely. Keep on the good work.
>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)
Cocoon needs most consolidation. I live currently off 2.1-HEAD, and
I feel uneasy about it. I tried to go back to 2.0.3 but failed because
I am addicted to some features currently only in HEAD.
I don't care if it is called 2.0.4, 2.1, or 2.1alpha but I'd appreciate
a fixed baseline including the most useful stuff from HEAD. My personal
shortlist is TreeProcessor with component inheritance in subsitemaps
working and the pipeline "expires".
>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.
It sure does. It shows that a lot of brainpower went into Cocoon.
>--
>Stefano Mazzocchi <[EMAIL PROTECTED]>
>--------------------------------------------------------------------
Cheers, Alfred.
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
