Carsten Ziegeler wrote:
Now as we have 2.1.5 out, I think we should talk about the future
a little bit - we already have discussed several things in the past and I want to try to summarize things.
First, I heard in the past complains from users at conferences where
I presented Cocoon, that it's not identifiable what our plans for
the future (or for upcomming versions) are. We often discuss this
openly in our mailing lists, but we rarely put the results to a
prominent place (TODO/planning document). So imho we should at least
try to do this :) (and yes, I'm of course guilty for not doing this
as well).
We need also to organise our docs so that "modern" techniques are explained first, in order for newbies not to get lost in the amount of possible ways to solve a problem.
Ok, the first plan for the future is obvious: the move to svn :)
But what else?
We have come to the conclusion that real blocks might take a little bit
longer than we have expected. So we agreed on not affecting the
current development of Cocoon by the real blocks development. Which means
we have to develop the blocks system separately from Cocoon
until the block system is stable enough to be "merged" into Cocoon. This allows us to release new versions of Cocoon (like 2.2)
without waiting for blocks to be working/finished.
We started with Cocoon 2.2 right after the release, so we can
put anything into it we want. I hope to implement the virtual
sitemap components soon, for example. I guess (fear?) that we will
have one or two maintenance releases for 2.1.x (2.1.6 etc.). For example fixing the dispose problem in the tree processor.
In general, I think we should try to see 2.2 as the "consolidation
version". In the past we added a lot of features, blocks, components
which resulted in the fact that we have in some places concurring solutions that could be combined a little bit. One good example is form handling where we agreed on concentrating
on CForms. We could try this in other areas as well.
Of course this does not mean that we shouldn't add new features
for 2.2, but imho we should try to consolidate what we currently
have as well.
Some things that come to my mind for 2.2:
- first finished version of CForms.
- deprecate XSP (and provide a viable alternative)
-1: XSP has been moved to its own block meaning it's no more "core", but hundreds (if not thousands) or people are using it on a daily basis. We can drive people towards new techniques such as flow/jxtemplate, but cannot deprecate what's has been a central part of Cocoon for so many years.
Personal note: your post made many people rush into my office saying "What, what, deprecate XSP? He's crazy!" ;-)
- cleaning up the caching/store mess
What's left to do here?
- remove deprecated blocks etc.
Mmh... this breaks compatibility. Taking Ugo's idea, what about creating an additional categorization level for blocks, such as "experimental", "samples", "applications", "deprecated", "archive"?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
