cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Micro-Cocoon ... Corona
Date Thu, 13 Mar 2008 18:34:41 GMT
Hi Reinhard,

Reinhard Poetz pisze:

> 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
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
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
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

> Any feedback is highly appreciated!

Best regards,
Grzegorz Kossakowski

View raw message