Torsten Curdt wrote:
IMO Cocoon should go the same way. The recent thread
about a complete rewrite of Cocoon *really* scares me
and a lot of people I've talked to as it will break
compatibility for sure.
Fear has always been the main blocker for new technologies.
Well, I haven't talked about what my (many's) fear is: We have been talking
about blocks for ages. After years we will get them. We are good in talking
about design and architecture but the usual Cocoon committer can only dedicate a
fraction of his time to enhance and improve Cocoon.
Considering this situation I have the fear that we will have a good concept (and
maybe some prototyp) in the end, that will block all future improvments as
everybody is waiting for the much, much better next revolutionary step.
Compared to this I like Daniel's vision much more because he outlines a way how
we get major improvments evolutionary. After splitting up Cocoon in many small
parts (blocks) and refactoring them to POJOs, we can reimplement the core which
should become much simpler if the core has been stripped down to its minimum.
This also makes it much easier for us to keep our *current* userbase as they can
follow us making small steps. This also has a positive impact on the quality
because we never have the chicken-egg-situation that we are waiting for users
that should use the new, shiny (alpha) version of Cocoon and they are waiting
that the new Cocoon gets officially realeased. As Mr. Javaflow you should know
this situation ;-).
I do not fear new technologies - I'm maybe the only one who is using Cocoon from
trunk in a serious project - but I do fear making the same mistake that we did
with 2.1 --> 2.2 again.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
