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
