Re: lenya 2.2 or lenya 3 (was Re: Website update)

Hi Thorsten, hi all

+1 for outsourcing and put the design down.

But at the fist step don't we have to decide if we based on C2.1, C2.2 
or C3 ? have to bring a vote ?

After, for the design writing, how we begin ? Lenya is a pretty "big 
app" and many entries points can be used to do the design : process, 
uses-cases, api, user interface,...

You (all of devs) have a design document with the mains points/heading 
to fill down that you can share ?
Such a guideline will help all of us to express I think.

Cheers

On 04/06/2010 10:29, Thorsten Scherler wrote:
> On Thu, 2010-06-03 at 12:29 +0200, Andreas Hartmann wrote:
>> Am 03.06.10 11:52, schrieb Michael Wechner:
>>> Andreas Hartmann wrote:
>>>> Am 03.06.10 00:54, schrieb Richard Frovarp:
>>>>> Since 2.2 is dead at the moment,
>>>
>>> what is the reason that it is dead?
>>>
>>> Technical or human resource reasons? Or other reasons?
>>
>>    From my PoV there are the following reasons:
>>
>> * Not enough interest from the community. Which is perfectly
>> understandable given that it is "only" a technology update, not a
>> functional upgrade.
>>
>> * Cocoon 2.2 is not state of the art anymore, it has been supplanted by
>> Cocoon 3.
>>
>> * IMO Cocoon 2.2 has some advantages over 2.1, but it is not really
>> groundbreaking. It feels like a step in the right direction, but there
>> are some issues which seem to be not quite polished yet. Many new
>> concepts are cool (reloading classloader, servlet-service framework),
>> but they come with some issues which are really annoying (like e.g.
>> class loading conflicts).
>>
>> * The migration requires some fundamental changes to the Lenya
>> architecture (dependencies etc.) which would need a lot of work (IIRC I
>> wrote a mail about this).
>>
>> * Maven is a whole different beast than Ant. The entry barrier is quite
>> intimidating.
>>
>>
>> To summarize: The benefits of upgrading to Cocoon 2.2 don't seem to
>> justify the effort. The Lenya product is very likely to become more
>> complex and complicated. I think there are more important issues we have
>> to address, like making the user experience more pleasant and improve
>> the feature set.
>>
>> I still think we should rather try to simplify the back-end by moving to
>> a mature standard repository that takes care of the complicated stuff
>> like concurrency, transactions, versioning etc. and focus on a nice rich
>> GUI. Cocoon is great for document and data processing, but nowadays
>> everything is dynamic and the user doesn't want to wait for the server
>> to assemble the page. Doing complicated things on the server, e.g. in
>> XML pipelines, always comes with an overhead which the user can't influence.
>>
>> I'm not implying that we should abandon Cocoon (quite the contrary), but
>> I have the feeling we're doing too much with Cocoon which should rather
>> be done with different technologies (especially client-side ones). And
>> for the things that are a perfect match for XML pipelines (like e.g.
>> i18n and link rewriting), Cocoon 2.1 is IMO sufficient.
>
> I totally agree with Andreas on most parts of his statement. I feel the
> need to architectural re-design Lenya to better leverage our resources.
> The current product can be labeled stable but limited.
>
> The jcr situation is becoming ridículos and the overhead of self
> implemented components rather then standard ones has practically stopped
> user contributions. Things like our workflow engine, repository
> implementation, etc. can be outsourced. This way we can concentrate on
> implementing CMS functionality.
>
> Cocoon3 (c3) is concentrating on the things which made cocoon famous and
> since now without competition. For doing the presentational layer and
> connect to different datasources to get xml from them. So let us define
> the various alternatives to replace our own implementation with standard
> components. I personally made very positive experience with Apache
> Wicket for forms and there is a wicket integration in c3.
>
> However I thing we first put the design down on paper/wiki and then we
> can distribute the workload under all of us.
>
> ...but the most important thing is that this design is community driven,
> meaning do not wait for e.g. me or Andreas to do the first step.
>
> salu2