Joerg Heinicke pisze: > It seems we do not even know the requirements. How do you want to decide > about architecture without them? My guess - since Cocoon is just a > framework - you merely get the requirements from real applications built > on it. Why can't we wait until the people get used to the new > functionality and see how it works out to see what can be removed in the > future?
Waiting a little bit and let the requirements to crystallize is a good idea in general. The process of crystallization of ideas will shape replacements for the functionality we want to deprecate. At the same time we can (and should in my opinion) deprecate things without having "1-1" replacements or even ideas for them. Why can't we wait? Because cocoon: + map:mount combo is a major pain whenever one wants to touch Cocoon's core. I'm almost sure that there is no active committer that could say: I know how this stuff works or at least I could figure out everything I need to work with this code in a day. Don't you think that having big portion of such code in core will bite us in the future only if it's not biting us now? Deprecation of this stuff would hold mainly informative role spreading a clear message: We really want to remove this code and we are actively evaluating various options as replacements. I would even say that deprecation would elicit active discussion amongst our users. That would be the best outcome of the whole deprecation thing at this point because we probably could gather a lot of useful information how Cocoon is used. Yes, as several folks pointed out, deprecation is only the first step to remove any portion of code. > From what I understand servlet protocol lacks some major functionality > like the fall-through of sub sitemaps. This seems to be the most > important convention over configuration feature. Can you explain what do you mean by "fall-through of sub sitemaps"? >> If people don't want to migrate I would tell them to stick to 2.1, >> it's stable and final release of >> 2.2 won't make 2.1 unusable. > > I want them as testers sharing their experience. Otherwise it takes much > longer to get peoples to use Cocoon 2.2 in a meaningful way (= more than > starting with little applications). I don't see the point preventing > people from migrating. Also we are talking about *deprecation* in 2.2 > here, not removing features. So how should it affect them? There would be no impact on our users apart from the psychological aspect I spoke about earlier. Do we agree on deprecating this stuff then? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
