cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [IT] C2 Complexity Syndrome
Date Fri, 27 Oct 2000 23:46:28 GMT
Niclas Hedhman wrote:
> 
> [Irrational Thought]

While I totally understand your irrational thought, please, allow me to
answer this with a little rationality, this won't remove your concerns
(being irrational, as you suggest), but might suggest your rational side
ways to influence your irrational side.

Note, I'm not being sarcastic, I really mean what I wrote: as Giacomo
says, we are biased and somehow blinded... but I've talked to many
people in the conference and was wonderful to hear comments such as
"Cocoon is totally cool" or "those guys really know what they're doing",
expecially when I didn't wear my badge :)
 
> Watching the frenzy of the development of Cocoon is rather interesting.

That's for sure.
 
> However, looking from a bit of a distance is perhaps a sobering exercise
> as well.
> WHat I find is that Cocoon is getting complexer and complexer by the
> hour, and soon it is reaching a stage where you won't understand, nor be
> able to use it effectively if you are not part of the development team.

I believe this can be said for almost anything: linux, apache, php, gcc,
emacs, gnome, kde, gimp, samba, perl, openoffice, netbeans... just to
name a few.

The key idea is "easy things should be easy, hard things possible". I
would personally add, "the hard stuff possibly easier with Cocoon than
with other technologies".

Also, you guys must understand that Cocoon is not intended to be used
for small sites and the cost of starting a Cocoon project is many times
higher than starting a normal HTML one, for example, with JSP or PHP.

Cocoon shows its power in the longer run, as the site becomes more
complex and you need more and more people to manage it. This is where
it's fair to compare it with other technologies.

> My fright is that Cocoon will be so powerful and hopelessly impossible
> to understand, that it will sink from its own weight.

I don't, but I have good reasons for that, see below.
 
> What problems do we have at hand?
> First of all, understanding it.
> The biggest problem for any new user must be to understand an iota of
> how things hangs together, and how do you structure a project, what does
> all the components mean and what is the actual functionality, what is
> the purpose of the sitemap and many other things regarding the overview.

Solution: write docs.

Any project is useless without documentation. Cocoon2 does not have
documentation, so this is like "shooting on the red cross" as we say in
Italian.

Almost any IT book publisher wants me to write a book on Cocoon,
wouldn't that help?

> Secondly, the difficulty to set it all up.
> There are step by step instructions that are pretty good, but if you
> deviate from it just a little bit, it is bound to become a nightmare.

Sorry, but this is bullshit: when Cocoon2 is released as a war file,
it's a matter of copying it into a directory and launch Tomcat. Period.
Nothing else to do, not even touching a single line of code. If you
think this is still too complex, please help me because I can't think of
anything simpler than this on a OS-independent server enviornment.

> This is to a large extent not directly the fault of Cocoon, but the fact
> that Cocoon is a too powerful servlet, part of a bigger framework.
> I believe these issues are being resolved in Tomcat.

yes

> Thirdly, configuration.
> Most users don't want to hack around in the sitemap.

???

Please define "user". "End users" for sure don't even know a sitemap
exists. "Content writers", "logic programmers" and "style designers"
must *NOT* be aware of the sitemap, imagine touching it. 

We are left with "site managers".

And you say that "site managers" don't like to hack around in the
sitemap? really? and what does your web manager do when he creates
aliases in httpd.conf or installs perl modules or PHP files?

Your irrational bad feeling comes from the fact that you picture
"yourself" doing all the work on a site that you can handle yourself....
well, then I agree with you: don't use Cocoon, since it's way too
complex for what you need.

Why separating concerns if people share them?

> They will not write
> their own selectors, transformers and so on. They want a set of
> pre-defined working templates.

This is *exactly* what sitemap inheritance is for. Again, think at the
difference between httpd.conf and .htaccess files for Apache: the first
is the main "mile long" thing, the rest are small local modifiers that
inherit the properties they don't change.

Cocoon simply makes it more elegant using XML and OOP design patterns.

Once "inherited" the big sitemap that Cocoon ships (which complexity is
managed by us developers, just like httpd.conf is already sent big and
fat inside Apache with lots of comments), it's just a matter of writing

 <match pattern="/page*">
  <generator src="/home/niclas/docs/page{1}.xml"/>
  <transform src="/home/niclas/style/fancy.xsl"/>
  <serialize/>
 </match>

and that's it.

Tell me, is that *so* incredibly hard you won't be able to use it?
Again, if you have ideas on how to reduce the verbosity even more,
please, tell me, because I spent months on this and I love it so much I
probably don't see its problems.

> They want XSP to work out of the box,
> without any manual hacking in the sitemap. Don't expect the average site
> manager to be a fluent Java programmer, he/she is not. At best, he/she
> has the resources in-house, more likely is that they must be purchased
> from the outside, hence customized generators and transformers are not
> part of a commoner's day.

Other bullshit: you don't hire the first newcomer as a web master.
Period. And if you givem them the power to manage their own sitemap like
the fragment above, it's not that complex that you can't teach them in a
couple of hours what to do and how to replicate the thing for another
set of documents.

Of course, if they need more fancy integration with the logic concerns,
then you need a more expert sitemap developer, but this already happens
for Apache, I don't understand the difference in model.

> Fourthly, source code.
> Source code is getting fairly complex, especially compared to the C1.
> I see a danger in this. I don't know how many has tried to figure out
> how the sitemap generation/compilation is done. I hope quite a few,
> since OSS projects are always faced with the fact that any single
> individual might disappear by a day's notice.

Here I totally agree and I've bugged by some contributions on this
project: submitting "blackboxware" doesn't create communities. Dumping
50 classes in a day and disappearing for 2 months is not the same thing
as taking two months to build 50 classes and leaving the community with
50 days with nothing the works.

The first kills communities, the second enlarge them and make them
healthier.

At the same time, open source dynamics show that there is no such thing
as unreadable code and refactoring, simplification and modularization
happen anyway, one day or another.
 
> Fifthly, feature bloat.
> Just because it can be done, doesn't mean it has to be implemented. The
> charm with C1 was it's simple approach to every day life.
> I guess I am part of the feature bloat, just as most enthusiasts are,
> and Stefano has tried to dodge the requests rather well, to a point
> where we are today.

I thank you for this since you were one of the first to accuse me of
stopping any extension to the original feature list :)

The fact that I don't name "FS" everything on this list is not because
I've grown soft on it, but it's because you people learned about
smelling the air for hidden side effects that might appear in the
future.

Experience makes a real difference while "smelling the air", but I
seriously think you guys use the "is it FS or not?" design pattern more
and more.

Actually, this is not a design pattern, but a metapattern: a pattern
about patterns.
 
> I just want to Raise a Condition, that I believe exists, and is the
> greatest threat to Cocoon's long-term survival. As soon as C2 stablizes
> a little bit more, most of the effort must be put into "friendliness",
> perhaps in form of presets, wizards, tools, or whatever. I believe a
> higher-level of Configuration layer is needed, that can better be
> communicating with configuration tools and such.
> 
> Just my USD25 worth of thought.

Believe me, Niclas, I'm fully aware of this. While evengelizing Cocoon
around the world, I get to feel with my hands the "reality of things",
that is not simply drawing on my whiteboard in my room and code an
elegant design....

... BUT, I guarantee you that that elegance pays off, first because an
elegant design is solid and easier to understand, even if very complex,
once the outline ideas are explained; second, Cocoon's job is to guide,
help and create itches that others scratch.

I'll tell you this: there is a very high chance that Cocoon will have a
working authoring companion by the end of this year. Of course, APLed
Java.... I don't expect it to be finished or polished or anything, but
at least I expect it to catalize development on things like visual
sitemap administration, schema-drivern XML editing and hopefully
XSLT/XSP visual authoring.

Cocoon is complex because it needs to be so.

But does not mean that we can't make it easy for people to use it... and
we'll do, that's for sure... otherwise, yes, I totally agree, this
project is born dead.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



Mime
View raw message