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!
