cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <stevend...@gmx.at>
Subject Re: Micro-Cocoon ... Corona
Date Thu, 13 Mar 2008 21:51:51 GMT
Hi guys,

I guess its about time to write something myself...

As a colleague of Reinhard I participated in the Micro-Cocoon effort in 
February.
Just as Reinhard wrote, at the end of those 3 days, there was the idea 
of doing a rewrite.

The number of use cases and the appr. 5500 lines of code indicated by 
Cobertura made this idea seem like an attainable goal.
Nonetheless this is/will be a challenging task - and I am attracted to 
challenges. ;-)
We believed that a working sitemap interpreter (without any components) 
could be created in about two days time.
So I simply attempted to do so and so far things are developing as we 
envisioned.

Very soon we decided to go back to the community and talk about our 
intention.
Of course we anticipated questions or even "mild resistance", but this 
all very natural.
So here we go...

> 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".
>   
That's the reason we're doing this as early as possible. Our intention 
is not to come up with something we developed for month and present a 
completed product.
Actually not much has happened yet. All we did was to build the minimum, 
just to convince ourselves our approach is actually working.
We believe it doesn't make much sense to come up with some grand idea 
without having anything that indicates this could work.
>   
>> 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?
>   
Maybe I'm getting this wrong, but as far as I understood there are 
already components that do not produce XML content, like the Reader.
I believe it's not that far fetched to think about transforming the 
output of that.
The use cases proposed by Bruce all seem reasonable to me.
>   
>>  . 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.
>   

First of all, there is not much to worry about. We're talking about 4.5 
days worth of thinking, planning, and developing.
That's not much compared to the about 10 days (3 days with 3-4 people) 
we spent here in Vienna in February.

I believe the fact that I'm not a Cocoon commit is actually an advantage 
here. It allowed me to think "out of the box" and be unaffected by the 
current implementation.
After all we're talking about a rewrite. Wouldn't make much sense, if we 
did everything the same way, would it.
Of course this means some things are different than Cocoon is now. But 
I'm confident any Cocoon committer can easily understand Corona and draw 
parallels with the current Cocoon.
The basic concept - like the sitemap, pipelines, etc. - are still the 
same, just reimplemented.
The current code base consists of about 750 lines of code (according to 
Cobertura). So there isn't much code to be understood either.

Having participated in another open source project - and knowing 2 
committers for some years - I believe I do understand open source 
communities.
I have no need to impose my ideas or code (or myself for that matter) to 
anyone and I'm well aware of the fact that "my code" is going to be 
changed (if it is adopted somehow) - maybe even in ways I'm not going to 
like.
I'm sure we will agree on some course of action, whether this means 
Corona is going to be adopted or not.

I'll leave it up to Reinhard and you to work out the next steps and how 
to proceed.
Of course I'd be happy to see Corona going open source and continuing to 
work on it. And who knows, in the end I even might become a committer... ;-)


Looking forward to hearing from you,
Steven
>   
> 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!
>>     
>
>   

Mime
View raw message