Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of grek@tuffmail.com designates
 216.86.168.178 as permitted sender)
Message-ID: <47D973C1.3080106@tuffmail.com>
Date: Thu, 13 Mar 2008 19:34:41 +0100
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20070801)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Micro-Cocoon ... Corona
References: <4777C8C7.6060807@apache.org> <47D94AE8.7010900@apache.org>
In-Reply-To: <47D94AE8.7010900@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Reinhard,

Reinhard Poetz pisze:
<snip/>

> That was the time when the idea of a rewrite was born. (And as I know it
> is important for Grzegorz I want to say that he wasn't involved into
> this rewrite in any ways.) I know, rewrites are a difficult topic
> especially in the context of open source projects but it was just too
> tempting. Our time budget was that we wanted to invest another three
> days (since it is Steven, a colleague at Indoqa and I, which is 6 days
> in total) into a rewrite and find out how far it will take us and to get
> another time estimation. So far we have invested about 4.5 days of those
> 6 days and the results are promising.

First of all I would like to say that it wasn't me who opted for rewrite option. My idea of Micro
Cocoon has been to have something derived from Cocoon 2.2 with *continuous* history. For me it was
quite important to have basic contracts preserved.

To be honest, I'm not feeling fine with the progress of events because I'm feeling like an outcast a
little bit. I feel like I was really involved in pushing Cocoon forward and now, when there is
Corona my opinion doesn't matter because development is isolated in Vienna's office. That I would
not call a "rewarding experience".

> This rewrite that we gave the name "Corona" consists of
> 
>  . a pipeline API (that isn't limited to XML pipelines but would also
>    support connecting of any types of pipes)

I second question of Reinhard. If not XML, then what? What's the use-case?

>  . a sitemap interpreter that interprets the sitemap language of 2.1/2.2
>    (pipeline, match, generate, transform, serialize, redirect, read,
>     handle-errors, act)
>  . the pipeline API and the sitemap interpreter are useable from within
>    *plain Java code* (-> no dependency on the Servlet API) --> if it is
> used
>    outside of a web container, the user has to make sure that there is no
>    component that uses the servlet API

Interesting but not sure if much practical.

>  . component lookups are hidden behind an own interface so that any
>    component container can be used - as you might guess, our current
>    implementation currently uses Spring but writing e.g. an OSGi component
>    provider would be simple
>  . some basic components (resource reader, file generator, XML
> serializer, etc.)
>  . expression language support in sitemaps
>  . thanks to the servlet-service framework, it should work with
>  . a demo servlet that uses the sitemap interpreter
> 
> Corona is inspired by Cocoon 2.x but doesn't use any of its interfaces.
> The only exception will be the JNet source resolver[5] that we will
> integrate very soon.

What's the advantage of JNet compared to CocoonSourceResolver? Is there any description available?

> Apart from that we will also integrate the Include-Transformer, the
> XSLTTransformer, provide support for controller implementations, provide
> components to use servlet-services from within pipelines and support
> pipeline caching. Then we should be able to run the tests cases[3] of
> Micro Cocoon which is enough if it is "only" pipeline processing that
> you need.

Hmmm. I presume that Corona won't support any of existing components of Cocoon 2.2? That are *very*
bad news IMO.

> So far Corona has been developed mostly by Steven (~ 90 % by him, 10 %
> by me) behind closed doors but we would like to change that, if this
> community is interested in adopting it in this or that way. Is there any
> interest and if yes, how should we proceed?

I've met Steven and I really like him (if you are reading this, greetings from me) but the fact that
90% of the code, fundamental contracts was developed by one developer which is *not* Cocoon
committer really worries me.

Anyway, I won't moan as long as I don't see the code because it is exactly what I'm interested in
mostly.

> Any feedback is highly appreciated!

-- 
Best regards,
Grzegorz Kossakowski