You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2004/08/01 15:23:02 UTC
[roadmap] Cocoon 2.2
Steven Noels wrote:
> On 30 Jul 2004, at 12:07, Vilya Harvey wrote:
>
>> A scripting language feels like overkill for simple pipelines, but
>> the XML syntax is very awkward for more complicated ones. The
>> appropriate choice comes down to how soon you feel that cutoff
>> occurs, for the kind of sites you develop.
>
>
> If the complexity of a sitemap becomes too troublesome to express
> using XML, I'm pretty sure adding yet another concern to the same
> artefact won't help - quite the contrary. I'm pretty sure some
> sitemaps "out there" are simply too complex because people use all
> sorts of twisted pipeline constructs and components, just to avoid
> writing some lines of flowscript or an Apple, or use Java proper. What
> some people feel like a disadvantage (splitting flow and pipelines
> into separate artefacts), I feel like a distinct advantage of Cocoon.
> With my peanut brains, I'm able to understand more advanced Cocoon
> apps when I see a <map:call function|continue> and some internal-only
> pipelines which are called by flow functions with a well described Map
> of input parameters. This is all highly personal, of course.
>
> </Steven>
I support this. Maybe there are some users out there who feel
uncomfortable that we discuss a lot about our fundamentals and the
things they have based their work on. I think this is the base for
inventing something new or finding better solutions because this gives
you the chance of looking at things from a different angle.
I want to say that I like the way how Cocoon works _today_. I really
like the separation of the declarativ sitemap and the procedural
controller. I don't think this is clumsy or somethink else and it really
helps to _understand_ web applications. I admit that it may be
simpler/shorter to write all your stuff into one ???map but this can't
be declarativ any more and this would destroy a lot of the
understanabilty of Cocoon, of course, this is very personal.
IMHO we should focus on _polishing_ the things we have now. We would
need a bunch of Flowscript components for database access, mailing,
webservice integration and maybe more, we have to split up Cocoon into
smaller pieces (I'll set up a proposal for this soon) so that it doesn't
feel like a monolith any more and that we become more flexible and we
finally have to work on a reference documentation that gives the user a
sense of having a complete doc in her hands.
Something that I'm currently missing too, is a well defined roadmap for
Cocoon 2.2.
The major points IMO are:
- splitting up Cocoon into smaller pieces (a
prerequiste for Cocoon Blocks)
- Virtual Sitemap Components, inheritable views
- move from ECM to Fortress
- stable Cocoon Forms
- complete reference documentation
After agreeing on the things that we want to become part of Cocoon 2.2,
we should define milestones so that our users have an idea where we want
to go and when we think we will arive.
Thoughts?
--
Reinhard
Re: [roadmap] Cocoon 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Reinhard Poetz wrote:
>>>
>>>> I also want to split up Cocoon as discussed by Unico and me a few
>>>> weeks ago
>>>> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109025350512527&w=2)
>>>
>>>
>>>
>>>
>>> Are you preparing a list of classes which would go to spi / api /
>>> common
>>> (core) / internal? Or you want to prepare the list after the vote? I'm
>>> not so clear on difference between spi/api, the list might help in
>>> understanding/voting.
>>
>>
>>
>>
>> Yep, preparing a list based on some experiments on my laptop will be
>> the first step. I have to admit that I'm not so clear neither at the
>> moment. Next week I will invest some time.
>
>
>
> I'm not so clear either on API/SPI ;-)
>
> So what about starting by public/internal? We can split public classes
> in API/SPI later on if we feel the need for this separation.
>
> Sylvain
>
Makes sense
--
Reinhard
Re: [roadmap] Cocoon 2.2
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>
>> Reinhard Poetz wrote:
>>
>>> I also want to split up Cocoon as discussed by Unico and me a few
>>> weeks ago
>>> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109025350512527&w=2)
>>
>>
>>
>> Are you preparing a list of classes which would go to spi / api / common
>> (core) / internal? Or you want to prepare the list after the vote? I'm
>> not so clear on difference between spi/api, the list might help in
>> understanding/voting.
>
>
>
> Yep, preparing a list based on some experiments on my laptop will be
> the first step. I have to admit that I'm not so clear neither at the
> moment. Next week I will invest some time.
I'm not so clear either on API/SPI ;-)
So what about starting by public/internal? We can split public classes
in API/SPI later on if we feel the need for this separation.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [roadmap] Cocoon 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>
>> I also want to split up Cocoon as discussed by Unico and me a few
>> weeks ago
>> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109025350512527&w=2)
>
>
> Are you preparing a list of classes which would go to spi / api / common
> (core) / internal? Or you want to prepare the list after the vote? I'm
> not so clear on difference between spi/api, the list might help in
> understanding/voting.
Yep, preparing a list based on some experiments on my laptop will be the
first step. I have to admit that I'm not so clear neither at the moment.
Next week I will invest some time.
--
Reinhard
Re: [roadmap] Cocoon 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> I also want to split up Cocoon as discussed by Unico and me a few weeks
> ago (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109025350512527&w=2)
Are you preparing a list of classes which would go to spi / api / common
(core) / internal? Or you want to prepare the list after the vote? I'm
not so clear on difference between spi/api, the list might help in
understanding/voting.
Vadim
Re: [roadmap] Cocoon 2.2
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
>
>> Imagine a VSC using a view is used in a sub sitemap :)
>
>
> Can't... Can you explain how VSC can use a view? No component
> currently is able to use a view, IIUC.
Ok, I used the wrong wording : it should be "a VSC defined in a parent
sitemap has a label that triggers a view inherited from a sitemap
ancestor of the one where the VSC is declared."
More concretely, considering the sample webapp, this can be the
"pretty-content" view defined in the root sitemap.xmap, triggered by a
virtual transformer defined in samples/sitemap.xmap having the "content"
label, itself being used by a pipeline e.g. in samples/i18n/sitemap.xmap
> Or, do you mean, VSC containing view labels? Labels are passive by
> themselves so there is no problem with that - view invoked in a
> (((...)sub)sub)sitemap currently uses labels on a component regardless
> of sitemap where labels were originally defined.
>
> And, for the record, I still think that labels within VSCs are not a
> good idea [1], in my mind VSC has semantics of a *component*, not
> semantics of a syntactic *sugar* [2].
I don't have a strong opinion about this, but tend to agree with you.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [roadmap] Cocoon 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
> Imagine a VSC using a view is used in a sub sitemap :)
Can't... Can you explain how VSC can use a view? No component currently
is able to use a view, IIUC.
Or, do you mean, VSC containing view labels? Labels are passive by
themselves so there is no problem with that - view invoked in a
(((...)sub)sub)sitemap currently uses labels on a component regardless
of sitemap where labels were originally defined.
And, for the record, I still think that labels within VSCs are not a
good idea [1], in my mind VSC has semantics of a *component*, not
semantics of a syntactic *sugar* [2].
Vadim
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109025616414081
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109007624409672
Re: [roadmap] Cocoon 2.2
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>>...and how will relative sources be resolved in an inherited
>>view called from a VSC defined in a parent sitemap?
>>
>>:-D
>>
>>or maybe it should be :-(
>>
>>
>>
>:) ..eh.. :(
>
>I think more and more that this VSC concept is way too complex. If
>we have such a problem to find a good solution for this problem
>how will users ever understand it? Hmmm.
>
>
IMO, the only way is to have a strict approach by requiring sources to
be absolute in VSCs. That means we leave this responsibility to the
user, and he will get a nice exception with a meaningfull message if
ever he provides relative URIs to the VSC.
And if ever a sensible approach appears to resolve relative URIs, we can
then relax the constraints in a backwards compatible way.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [roadmap] Cocoon 2.2
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> Carsten Ziegeler wrote:
>>
>>>> ...and how will relative sources be resolved in an inherited view
>>>> called from a VSC defined in a parent sitemap?
>>>>
>>>> :-D
>>>>
>>>> or maybe it should be :-(
>>>
>>
>> If you think about it, views do not have any parameters passed to
>> them. As a result, all resources which view uses are defined within
>> view itself, within sitemap where is is defined, so all view
>> resources must be resolved relative to the sitemap where view is
>> defined.
>
>
>
> Good point. That totally makes sense.
>
>> Can we achive this (if view are made inheritable)? Can such a
>> resolver be given to the view so it resolves *not* relative to the
>> current sitemap, but relative to the view declaration sitemap?
>
>
>
> The sitemap engine can add an additional transformer to the pipeline
> at the beginning of view execution, that will change the environment
> context when SAX events enter the part of the pipeline defined by the
> view (and sends SAX events verbatim to the next component in the
> pipeline).
Actually, this component already exists in
o.a.c.environment.internal.EnvironmentStack.EnvironmentChanger.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [roadmap] Cocoon 2.2
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
>
>>> ...and how will relative sources be resolved in an inherited view
>>> called from a VSC defined in a parent sitemap?
>>>
>>> :-D
>>>
>>> or maybe it should be :-(
>>
>
> If you think about it, views do not have any parameters passed to
> them. As a result, all resources which view uses are defined within
> view itself, within sitemap where is is defined, so all view resources
> must be resolved relative to the sitemap where view is defined.
Good point. That totally makes sense.
> Can we achive this (if view are made inheritable)? Can such a resolver
> be given to the view so it resolves *not* relative to the current
> sitemap, but relative to the view declaration sitemap?
The sitemap engine can add an additional transformer to the pipeline at
the beginning of view execution, that will change the environment
context when SAX events enter the part of the pipeline defined by the
view (and sends SAX events verbatim to the next component in the pipeline).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [roadmap] Cocoon 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
>
> If you think about it, views do not have any parameters
> passed to them.
> As a result, all resources which view uses are defined within
> view itself, within sitemap where is is defined, so all view
> resources must be resolved relative to the sitemap where view
> is defined.
Yepp.
>
> Can we achive this (if view are made inheritable)? Can such a
> resolver be given to the view so it resolves *not* relative
> to the current sitemap, but relative to the view declaration sitemap?
>
Yes, each sitemap has a resolver (EnvironmentChanger) that resolves
relative to this sitemap, so if we pass this into the components
in the view, we are finished.
Carsten
Re: [roadmap] Cocoon 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
>>...and how will relative sources be resolved in an inherited
>>view called from a VSC defined in a parent sitemap?
>>
>>:-D
>>
>>or maybe it should be :-(
If you think about it, views do not have any parameters passed to them.
As a result, all resources which view uses are defined within view
itself, within sitemap where is is defined, so all view resources must
be resolved relative to the sitemap where view is defined.
Can we achive this (if view are made inheritable)? Can such a resolver
be given to the view so it resolves *not* relative to the current
sitemap, but relative to the view declaration sitemap?
Vadim
RE: [roadmap] Cocoon 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> >Sure. I suggested this a long time ago (and I think I wasn't
> the only
> >one).
> >*If* we implement virtual sitemap components we need
> inheritable views
> >anyway. Imagine a VSC using a view is used in a sub sitemap :)
> >
> >
>
> ...and how will relative sources be resolved in an inherited
> view called from a VSC defined in a parent sitemap?
>
> :-D
>
> or maybe it should be :-(
>
:) ..eh.. :(
I think more and more that this VSC concept is way too complex. If
we have such a problem to find a good solution for this problem
how will users ever understand it? Hmmm.
Carsten
Re: [roadmap] Cocoon 2.2
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Reinhard Poetz wrote:
>
>
>>>M2:
>>> - Virtual Sitemap Components
>>>M3:
>>> - Inheritable Views (hmm, where this came from?)
>>>
>>>
>>I remember a few discussions. Maybe Carsten can help here.
>>
>>
>>
>Sure. I suggested this a long time ago (and I think I wasn't the
>only one).
>*If* we implement virtual sitemap components we need inheritable
>views anyway. Imagine a VSC using a view is used in a sub sitemap :)
>
>
...and how will relative sources be resolved in an inherited view called
from a VSC defined in a parent sitemap?
:-D
or maybe it should be :-(
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [roadmap] Cocoon 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Poetz wrote:
> > M2:
> > - Virtual Sitemap Components
> > M3:
> > - Inheritable Views (hmm, where this came from?)
>
>
> I remember a few discussions. Maybe Carsten can help here.
>
Sure. I suggested this a long time ago (and I think I wasn't the
only one).
*If* we implement virtual sitemap components we need inheritable
views anyway. Imagine a VSC using a view is used in a sub sitemap :)
Carsten
Re: [roadmap] Cocoon 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Reinhard Poetz wrote:
>>
> >>>
>
>>>> What is a realistic date for the final release? December _this_
>>>> year? Then we could have M2 in October, RC1 by the end of November
>>>> and if necessary a RC2 before the final 2.2 release.
>>>>
>>>> WDOT?
>>>
>>>
>>>
>>> Not sure about others, but it seems like very optimistic plan to me.
>>> I'd plan to release M1 in December (this year).
>>
>>
>>
>> Don't know. Depends on what people plan to do. I think we shouldn't
>> wait to long with a M1 (IMHO December is too long), independently
>> from when we plan the final release.
>
>
> :-)
>
> Let's rephrase: do you think that M1 should be time-driven, or feature
> driven? If it is time-driven, then yes, you don't have to wait, you
> can release right now (or whenever) whatever is in SVN ;-)
that's the question. If we don't have anything new to publish or the
repository is in an unstable state it doesn't make sense. My point is
that we should define goals in a realistic way and we should try to
reach them.
> But if it is feature driven, it depends on what features will get
> included into M1, and also on availability of committers. Given my
> perception of availability, I feel like that M1 in less than two month
> is a bit too optimistic.
>
> Either way, we can (or can try to) come up with set of milestones
> (what consitutes which milestone) and document them in roadmap.
> Something to the effect:
>
> M1:
> - Move from ECM to Fortress
I also want to split up Cocoon as discussed by Unico and me a few weeks
ago (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109025350512527&w=2)
> M2:
> - Virtual Sitemap Components
> M3:
> - Inheritable Views (hmm, where this came from?)
I remember a few discussions. Maybe Carsten can help here.
> RC:
> - Complete reference documentation
>
> And stable Cocoon Forms can be part of 2.1.7, not necessarily part of 2.2
good point
--
Reinhard
Re: [roadmap] Cocoon 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>
>> Reinhard Poetz wrote:
>>>
>>> What is a realistic date for the final release? December _this_ year?
>>> Then we could have M2 in October, RC1 by the end of November and if
>>> necessary a RC2 before the final 2.2 release.
>>>
>>> WDOT?
>>
>>
>> Not sure about others, but it seems like very optimistic plan to me.
>> I'd plan to release M1 in December (this year).
>
>
> Don't know. Depends on what people plan to do. I think we shouldn't wait
> to long with a M1 (IMHO December is too long), independently from when
> we plan the final release.
:-)
Let's rephrase: do you think that M1 should be time-driven, or feature
driven? If it is time-driven, then yes, you don't have to wait, you can
release right now (or whenever) whatever is in SVN ;-)
But if it is feature driven, it depends on what features will get
included into M1, and also on availability of committers. Given my
perception of availability, I feel like that M1 in less than two month
is a bit too optimistic.
Either way, we can (or can try to) come up with set of milestones (what
consitutes which milestone) and document them in roadmap. Something to
the effect:
M1:
- Move from ECM to Fortress
M2:
- Virtual Sitemap Components
M3:
- Inheritable Views (hmm, where this came from?)
RC:
- Complete reference documentation
And stable Cocoon Forms can be part of 2.1.7, not necessarily part of 2.2
Vadim
Re: [roadmap] Cocoon 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> We have started to discuss the roadmap for 2.2 some time ago and the
>>> starting point is in this document:
>>>
>>> /cocoon/src/documentation/xdocs/plan/roadmap.xml
>>
>
> Found also:
> http://cocoon.apache.org/2.1/plan/release.html
> http://cocoon.apache.org/2.1/plan/samples.html
>
> Seems like outdated pages - should we remove them?
>> The document doesn't contain a scheduled release date for M1. I know
>> it's difficult to say when which parts will be ready. But if we
>> committers say which parts we are working on and when things will be
>> ready we get a sense for a timeline.
>>
>> I think we should release M1 by the end of September. I plan to
>> propose and to do the splitting up of Cocoon into smaller pieces by
>> then.
>> What do other people plan?
>>
>> What is a realistic date for the final release? December _this_ year?
>> Then we could have M2 in October, RC1 by the end of November and if
>> necessary a RC2 before the final 2.2 release.
>>
>> WDOT?
>
>
> Not sure about others, but it seems like very optimistic plan to me.
> I'd plan to release M1 in December (this year).
Don't know. Depends on what people plan to do. I think we shouldn't wait
to long with a M1 (IMHO December is too long), independently from when
we plan the final release.
--
Reinhard
Re: [roadmap] Cocoon 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>
>> We have started to discuss the roadmap for 2.2 some time ago and the
>> starting point is in this document:
>>
>> /cocoon/src/documentation/xdocs/plan/roadmap.xml
Found also:
http://cocoon.apache.org/2.1/plan/release.html
http://cocoon.apache.org/2.1/plan/samples.html
Seems like outdated pages - should we remove them?
> The document doesn't contain a scheduled release date for M1. I know
> it's difficult to say when which parts will be ready. But if we
> committers say which parts we are working on and when things will be
> ready we get a sense for a timeline.
>
> I think we should release M1 by the end of September. I plan to propose
> and to do the splitting up of Cocoon into smaller pieces by then.
> What do other people plan?
>
> What is a realistic date for the final release? December _this_ year?
> Then we could have M2 in October, RC1 by the end of November and if
> necessary a RC2 before the final 2.2 release.
>
> WDOT?
Not sure about others, but it seems like very optimistic plan to me. I'd
plan to release M1 in December (this year).
Vadim
RE: [roadmap] Cocoon 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Ugo Cei wrote:
> Il giorno 02/ago/04, alle 09:19, Carsten Ziegeler ha scritto:
>
> > But I think we shouldn't forget about 2.1.6; merging all
> the nice bug
> > fixes we already have in 2.2 into 2.1.x is imho currently as
> > important.
>
> We could dedicate the next FirstFriday (Aug. 6th) to it. WDYT?
>
+1
Carsten
Re: [roadmap] Cocoon 2.2
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 02/ago/04, alle 09:19, Carsten Ziegeler ha scritto:
> But I think we shouldn't forget about 2.1.6; merging all the nice
> bug fixes we already have in 2.2 into 2.1.x is imho currently
> as important.
We could dedicate the next FirstFriday (Aug. 6th) to it. WDYT?
--
Ugo Cei - http://beblogging.com/
RE: [roadmap] Cocoon 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Poetz wrote:
>
> Thank you.
> The document doesn't contain a scheduled release date for M1.
> I know it's difficult to say when which parts will be ready.
> But if we committers say which parts we are working on and
> when things will be ready we get a sense for a timeline.
>
Yes.
> I think we should release M1 by the end of September. I plan
> to propose and to do the splitting up of Cocoon into smaller
> pieces by then.
> What do other people plan?
I'm currently working on nothink related to 2.2, but I
want to move to Fortress in the next weeks; so this will be
in a M1 whatever date we choose for that.
But I think we shouldn't forget about 2.1.6; merging all the nice
bug fixes we already have in 2.2 into 2.1.x is imho currently
as important.
Carsten
Re: [roadmap] Cocoon 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
>
>Reinhard Poetz wrote:
>
>
>
>>After agreeing on the things that we want to become part of
>>Cocoon 2.2, we should define milestones so that our users
>>have an idea where we want to go and when we think we will arive.
>>
>>Thoughts?
>>
>>
>>
>We have started to discuss the roadmap for 2.2 some time ago and
>the starting point is in this document:
>
>/cocoon/src/documentation/xdocs/plan/roadmap.xml
>
>Carsten
>
>
>
>
Thank you.
The document doesn't contain a scheduled release date for M1. I know
it's difficult to say when which parts will be ready. But if we
committers say which parts we are working on and when things will be
ready we get a sense for a timeline.
I think we should release M1 by the end of September. I plan to propose
and to do the splitting up of Cocoon into smaller pieces by then.
What do other people plan?
What is a realistic date for the final release? December _this_ year?
Then we could have M2 in October, RC1 by the end of November and if
necessary a RC2 before the final 2.2 release.
WDOT?
--
Reinhard
RE: [roadmap] Cocoon 2.2
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Poetz wrote:
> After agreeing on the things that we want to become part of
> Cocoon 2.2, we should define milestones so that our users
> have an idea where we want to go and when we think we will arive.
>
> Thoughts?
>
We have started to discuss the roadmap for 2.2 some time ago and
the starting point is in this document:
/cocoon/src/documentation/xdocs/plan/roadmap.xml
Carsten