Re: Micro-Cocoon ... Corona
Reinhard Poetz pisze: 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. Well said, there isn't much to add. Grzegorz, I don't really understand what you are worried about. Is it because Steven is not (yet) an active member? Or is it because we developed Corona behind closed doors for about *4.5 days*? That not much time IMO. As Steven pointed out, we want to share the code with this community. It's not meant to be a finished piece of software where all contracts are cast in stone. It's rather the opposite. We would be more than happy to get detailed feedback on the chosen designs (The architecture is more or less the one of 2.x.) and we don't think that we got all things right at the first shot. We also don't have ego problems so that we couldn't take critisisms. I must admit I misunderstood the situation. I had different imagination (much exaggerated) of Corona compared to what it actually is. Now I'm glad to see that you want to share your work right from the beginning and let whole community participate in the effort (including me). I'm waiting impatiently to see this moving forward :-) Thinking further, in my opinion it is a great chance to attract new developers and users because one of the main goals of Corona is that it can be easily used from within different environments. This would mean that it may become attractive to many other (opensource) projects (again). I hope you (and many others) give Corona a chance and take a look at it. Agreed. What about officially announcing our effort at main site with simple manifesto? I have a feeling that we agree on fundamental goals so writing such a document shouldn't be a problem, right? I would like to see as many as possible people participating or at least aware of the move. -- Grzegorz Kossakowski
Re: Micro-Cocoon ... Corona
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: snip/ Thinking further, in my opinion it is a great chance to attract new developers and users because one of the main goals of Corona is that it can be easily used from within different environments. This would mean that it may become attractive to many other (opensource) projects (again). I hope you (and many others) give Corona a chance and take a look at it. Agreed. What about officially announcing our effort at main site with simple manifesto? I have a feeling that we agree on fundamental goals so writing such a document shouldn't be a problem, right? I don't think this is a good idea. The cocoon.apache.org website is for our users, and talks about stable or upcoming releases, even if 2.2 has been upcoming for years ;-) Corona is a different thing, because it is an experiment started by some members of the community, that other members are interested in looking at, and *may* become something we release in an unknown future, or simply be trashed if we decide it's an effort not worth pursuing. So it is way too early to talk about it to the people visiting cocoon.apache.org, especially as 2.2 is close to be released as final. Releasing 2.2 and announcing a revolution would give a very disturbing message. I would like to see as many as possible people participating or at least aware of the move. The move isn't decided yet. But you can count on the people on this list to jump in if they find it worth it. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Micro-Cocoon ... Corona
Grzegorz Kossakowski wrote:
Now I'm glad to see that you want to share your work right from the
beginning and let whole community participate in the effort (including
me). I'm waiting impatiently to see this moving forward :-)
Steven and I will need some more time to tidy up Corona. If time permits we can
publish Corona on Wednesday, otherwise on Friday.
Thinking further, in my opinion it is a great chance to attract new
developers and users because one of the main goals of Corona is that
it can be easily used from within different environments. This would
mean that it may become attractive to many other (opensource) projects
(again).
I hope you (and many others) give Corona a chance and take a look at it.
Agreed. What about officially announcing our effort at main site with
simple manifesto? I have a feeling that we agree on fundamental goals so
writing such a document shouldn't be a problem, right?
I plan to write a blog entry about it so that the information gets spread to a
wider audiance. For a public announcement it's too early, especially so close
before we release 2.2.
And don't forget, for the time being it's just Steven and I who have been
contributing to it. Given others showed their interest and I'm *really happy*
about this, but to make it a community-driven effort, active involvement by
others is required. Then it's up to the Cocoon PMC to decide about the next steps.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Micro-Cocoon ... Corona
Reinhard Poetz pisze: Agreed. What about officially announcing our effort at main site with simple manifesto? I have a feeling that we agree on fundamental goals so writing such a document shouldn't be a problem, right? I plan to write a blog entry about it so that the information gets spread to a wider audiance. For a public announcement it's too early, especially so close before we release 2.2. Thanks Reinhard and Sylvain for reminding me rules and best-practices to be applied in such situations. I agree that it's better to spread by using blogosphere and personal contacts. My main intention was to bring here old committers and people trying to do more or less the same[1]. I'm really looking for your blog-entry Reinhard. And don't forget, for the time being it's just Steven and I who have been contributing to it. Given others showed their interest and I'm *really happy* about this, but to make it a community-driven effort, active involvement by others is required. Then it's up to the Cocoon PMC to decide about the next steps. Ok. I'm young committer that happened to contribute to Cocoon in rather calm days so I don't know procedures to be undertaken in such situations. [1] http://kauriproject.org/wiki/65-kauri.html -- Grzegorz Kossakowski
Re: Micro-Cocoon ... Corona
David Crossley wrote:
Reinhard Poetz wrote:
Of course we are! We only have to work out the details of how we do it. The
main question is, if we have to go through ASF IP clearance or not.
Since it's rather a proposal than a finished project (~700 lines of code),
I think it's enough if Steven sends in an CLA and attaches the code to a
Jira issue.
In the meantime (until Steven's CLA is recorded) we could prepare a
snapshot package of Corona that we make privatly available to the Cocoon
PMC.
Is this a viable procedure?
I consider that it is.
It is your creative work, so it is just contributed
under your Individual CLAs. You and Steven declare that
you have the rights to contribute it.
For your benefit, you might need the Corporate CLA
if your ability to contribute is not clear with respect to
your employment agreement. Probably okay in your case.
All people working for/with Indoqa are free (and of course encouraged) to
contribute to opensource projects. That's also being made explicit in our
individual contracts with the company.
Thanks for your reminder: In my role as managing directory, I will also send a
CCLA to the ASF secretry to make this explicit.
Thanks David for your confirmation!
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Micro-Cocoon ... Corona
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Grzegorz Kossakowski wrote: Agreed. What about officially announcing our effort at main site with simple manifesto? I have a feeling that we agree on fundamental goals so writing such a document shouldn't be a problem, right? I plan to write a blog entry about it so that the information gets spread to a wider audiance. For a public announcement it's too early, especially so close before we release 2.2. Thanks Reinhard and Sylvain for reminding me rules and best-practices to be applied in such situations. The main thing is that we can only promote to users, stuff that we have released. I agree that it's better to spread by using blogosphere and personal contacts. My main intention was to bring here old committers and people trying to do more or less the same[1]. Grek also was seeking to clarify the goals of such efforts. We could have a developers' area of the website, or use the Cocoon Wiki, or just a README in the source. Label it as intended for developers. -David
Re: Micro-Cocoon ... Corona
Luca Morandini wrote:
Sylvain Wallez wrote:
So we can take a different approach, and consider that we can use
plain programming languages rather than grow our own
pseudo-languages. A well-defined Java API and its Javascript
binding would make people way more productive than an XML-based
language like the sitemap.
Do you mind terribly showing me an example of the use of this API ?
Something like:
CocooonStream stream= new CocoonStream(file, documents/mydoc.xml);
stream.transform(xslt, xsl/doc2html.xsl);
return stream.serialize(html);
Yes, something like that. But add in the mix the often discussed
content-aware selection (see [1] for the Flickr API):
CocoonStream stream = new CocoonStream(url,
http://api.flickr.com/services/rest/?method=flickr.test.echoname=foo;);
if (stream.inspect(xpath, /[EMAIL PROTECTED]'ok'])) {
doSomeUsefulApplicationStuff();
stream.transform(xslt, xsl/flickr-success.xsl);
} else {
stream.transform(xslt, xsl/flickr-error.xsl);
}
return stream.serialize(html);
I understand the usefulness of having a programmatic API and this
approach plays well with the Java monoculture, but, there aren't
libraries already doing that ?
I don't think we're talking about monoculture here, but about avoiding
the clumsyness of a reinventing a real programming language in XML. Such
an API can be mapped to the language of your choice: Javascript, Python,
Ruby, Scala or whatever language is available on the JVM, including but
not limited to the sitemap.
About existing APIs, javax.xml.transform addresses part of it (it
doesn't have stream inspection though) but it often perceived as
difficult to grasp from the simple fact that you have to wire the
pipeline backwards, starting with the serializer.
Sylvain
[1] http://www.flickr.com/services/api/request.rest.html
--
Sylvain Wallez - http://bluxte.net
Re: Micro-Cocoon ... Corona
Sylvain Wallez wrote: Luca Morandini wrote: Do you mind terribly showing me an example of the use of this API ? Something like: CocooonStream stream= new CocoonStream(file, documents/mydoc.xml); stream.transform(xslt, xsl/doc2html.xsl); return stream.serialize(html); Yes, something like that. But add in the mix the often discussed content-aware selection I remember that one, it was one of my first gripes with Cocoon, circa 2001... gee, that's 7 years ago ! I understand the usefulness of having a programmatic API and this approach plays well with the Java monoculture, but, there aren't libraries already doing that ? I don't think we're talking about monoculture here, but about avoiding the clumsyness of a reinventing a real programming language in XML. Point taken, though having a single place to look at in order to understand the URI routing has its merits. Moreover, since the introduction of Flowscript, the tricky things can be done in it, leaving the sitemap declarative syntax to what it does best. About existing APIs, javax.xml.transform addresses part of it (it doesn't have stream inspection though) but it often perceived as difficult to grasp from the simple fact that you have to wire the pipeline backwards, starting with the serializer. Ok, but... (bear with my my ignorance a bit more) is *that* difficult to develop such an API ? I mean, the classes dealing with the sitemap are already doing that, isn't just a matter of spreading an API over them ? Regards, Luca Morandini www.lucamorandini.it
Re: Micro-Cocoon ... Corona
Luca Morandini wrote: Sylvain Wallez wrote: snip/ About existing APIs, javax.xml.transform addresses part of it (it doesn't have stream inspection though) but it often perceived as difficult to grasp from the simple fact that you have to wire the pipeline backwards, starting with the serializer. Ok, but... (bear with my my ignorance a bit more) is *that* difficult to develop such an API ? I mean, the classes dealing with the sitemap are already doing that, isn't just a matter of spreading an API over them ? Oh, I don't think it's a giant task, and what we wrote in this thread is pretty close to the current pipeline interface [1]. But it was designed as support code for the sitemap because this was the target goal, and thus it contains some sitemap-isms. We probably need to polish it by thinking the other way around, i.e. start aim at a clean Java API on top of which we can add and XML language... if we want. Sylvain [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-api/src/main/java/org/apache/cocoon/components/pipeline/ProcessingPipeline.java -- Sylvain Wallez - http://bluxte.net
Re: Micro-Cocoon ... Corona
Reinhard Poetz wrote: Of course we are! We only have to work out the details of how we do it. The main question is, if we have to go through ASF IP clearance or not. Since it's rather a proposal than a finished project (~700 lines of code), I think it's enough if Steven sends in an CLA and attaches the code to a Jira issue. In the meantime (until Steven's CLA is recorded) we could prepare a snapshot package of Corona that we make privatly available to the Cocoon PMC. Is this a viable procedure? I consider that it is. It is your creative work, so it is just contributed under your Individual CLAs. You and Steven declare that you have the rights to contribute it. For your benefit, you might need the Corporate CLA if your ability to contribute is not clear with respect to your employment agreement. Probably okay in your case. -David
Re: Micro-Cocoon ... Corona
Daniel Fagerstrom wrote:
Peter Hunsberger skrev:
On Thu, Mar 13, 2008 at 10:40 AM, Reinhard Poetz [EMAIL PROTECTED]
wrote:
Reinhard Poetz wrote:
sniplots of cool stuff/snip
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?
Very interested. I'd second throwing it into the white board if
you're willing?
+1!
Of course we are! We only have to work out the details of how we do it. The main
question is, if we have to go through ASF IP clearance or not.
Since it's rather a proposal than a finished project (~700 lines of code), I
think it's enough if Steven sends in an CLA and attaches the code to a Jira issue.
In the meantime (until Steven's CLA is recorded) we could prepare a snapshot
package of Corona that we make privatly available to the Cocoon PMC.
Is this a viable procedure?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Micro-Cocoon ... Corona
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
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.
Ah, even cooler :) So far I haven't used JNet myself, so it seems you
found it usefull. If there is anything missing/not working just let me
know.
Thanks for the offer!
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Micro-Cocoon ... Corona
Bruce Atherton wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
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)
Do you have use cases for this? (Just curious)
I can think of a lot of them. Any time you want to make replacements in
text where the source is not XML this could be useful. How about
replacing property keys with property values, just as an obvious
example. Or translating a text file to another language by looking up
phrases in a resource bundle. Sure, you could use a templating engine,
but that may be overkill for some applications and besides, suppose you
wanted to do several unrelated replacements that used different kinds of
templates?
Or suppose you wanted to make changes to HTML generated by some other
website that doesn't generate XHTML or even very sensible HTML? There
are many reasons you might want to do this: to extract a bit of content
from the page, to filter certain words, to alter URLs. I wrote a spider
once that archived the state of a web application as of a certain day.
It crawled web pages and replaced URLs with file: URLs that pointed to
where the web page was stored locally. This was complicated by the fact
that many web pages with the same URL would display different data
depending on request parameters, and so had to be stored in different
places but still be pointed to by the links if you followed a particular
path through the stored HTML files. This was only one of many cleanups I
needed to make to the archived HTML. Cocoon didn't help me because there
was no reasonable way to get the HTML into XHTML. A non-XML pipeline
would have helped a lot.
yes, these are interesting use cases. Also image transformations might be a
possible use case.
But the main usecase I had in mind was XML pull pipelines because writing a pull
transformer would much easier than writing a SAX transformer.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Micro-Cocoon ... Corona
Steven Dolg wrote:
Grzegorz Kossakowski wrote:
Reinhard Poetz wrote:
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.
Well said, there isn't much to add.
Grzegorz, I don't really understand what you are worried about. Is it because
Steven is not (yet) an active member?
Or is it because we developed Corona behind closed doors for about *4.5 days*?
That not much time IMO.
As Steven pointed out, we want to share the code with this community. It's not
meant to be a finished piece of software where all contracts are cast in stone.
It's rather the opposite.
We would be more than happy to get detailed feedback on the chosen designs (The
architecture is more or less the one of 2.x.) and we don't think that we got all
things right at the first shot. We also don't have ego problems so that we
couldn't take critisisms.
Thinking further, in my opinion it is a great chance to attract new developers
and users because one of the main goals of Corona is that it can be easily used
from within different environments. This would mean that it may become
attractive to many other (opensource) projects (again).
I hope you (and many others) give Corona a chance and take a look at it.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Micro-Cocoon ... Corona
Peter Hunsberger wrote: On Thu, Mar 13, 2008 at 10:40 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: Reinhard Poetz wrote: sniplots of cool stuff/snip 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? Very interested. I'd second throwing it into the white board if you're willing? +1 Michael -- Michael Wechner Wyona - Open Source Content Management - Yanel, Yulup http://www.wyona.com [EMAIL PROTECTED], [EMAIL PROTECTED] +41 44 272 91 61
Re: Micro-Cocoon ... Corona
Steven Dolg wrote: 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. Nice work, I'm eager to have a look at it :-) 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. I wouldn't consider a sitemap interpreter as being a primary goal for Corona (or whatever its final name). This language was initially meant to be a simple and efficient way to define pipelines. Now over time features have been added and added again, because the complexity of what people had to do required it. And even with that, people have been very creative (even overly creative) in ways to distort or abuse the sitemap language because it was still too limited. So we can take a different approach, and consider that we can use plain programming languages rather than grow our own pseudo-languages. A well-defined Java API and its Javascript binding would make people way more productive than an XML-based language like the sitemap. My 0.02 euros Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Micro-Cocoon ... Corona
Carsten Ziegeler wrote: Reinhard Poetz wrote: 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? If you don't mind, commit it to the whiteboard. I'm heavily interested in the stuff :) +1. I'll be coming back in the XML transformation world pretty soon, and was already thinking about a super-lightweight pipeline library... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Micro-Cocoon ... Corona
Sylvain Wallez wrote:
Corona (or whatever its final name).
Sure, it's just a working title to make communication easier and to have a
unique namespace (Java packages, Spring beans, etc.).
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Micro-Cocoon ... Corona
Sylvain Wallez wrote: So we can take a different approach, and consider that we can use plain programming languages rather than grow our own pseudo-languages. A well-defined Java API and its Javascript binding would make people way more productive than an XML-based language like the sitemap. Do you mind terribly showing me an example of the use of this API ? Something like: CocooonStream stream= new CocoonStream(file, documents/mydoc.xml); stream.transform(xslt, xsl/doc2html.xsl); return stream.serialize(html); ? I understand the usefulness of having a programmatic API and this approach plays well with the Java monoculture, but, there aren't libraries already doing that ? Regards, Luca Morandini www.lucamorandini.it
Re: Micro-Cocoon ... Corona
On Mar 14, 2008, at 2:22 PM, Luca Morandini wrote: Sylvain Wallez wrote: So we can take a different approach, and consider that we can use plain programming languages rather than grow our own pseudo- languages. A well-defined Java API and its Javascript binding would make people way more productive than an XML-based language like the sitemap. Do you mind terribly showing me an example of the use of this API ? http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/LogicsheetCodeGenerator.java :-P Seriously - it does exactly the same thing you wrote just below: Vadim Something like: CocooonStream stream= new CocoonStream(file, documents/mydoc.xml); stream.transform(xslt, xsl/doc2html.xsl); return stream.serialize(html); ? I understand the usefulness of having a programmatic API and this approach plays well with the Java monoculture, but, there aren't libraries already doing that ? Regards, Luca Morandini www.lucamorandini.it
Re: Micro-Cocoon ... Corona
Reinhard Poetz wrote:
We at Indoqa have started to think about working on a slimmed down
version of Cocoon 2.2 (Micro-Cocoon).
snip/
Having said this, I want to mention that, for us, the Micro-Cocoon
effort is a feasability study, that we will conduct over the next 8
weeks.
Working on Mirco-Cocoon was an interesting experience. First Grzegorz, my
colleagues at Indoqa and I began with a code walk-through. Starting with the
second day we got our hands dirty and we did a lot of refactorings (remove
sub-sitemap support, remove sitemap-level components management, remove the
cocoon-protocol, cut some of the dependencies on Avalon/Excalibur, etc.).
In order to make sure that we don't break any functionality that we want to keep
working, I wrote integration tests (see [1] for the sitemap and [2] for the
integration test framework and [3] for the tests) which we let run whenever we
changed something.
This also gave us the chance to use Cobertura to find out how many lines of
Cocoon code are actually needed to make the tests run. The (for me) surprising
result was that of 23581 lines of code in Cocoon core, only 5510 are needed for
the test cases. See [4] for the full reports.
At the end of the third day we began to disucss how much work is still nessary
in order to reach the goal of a light-weight Cocoon. Our estimation is that it
will take somebody, who is familiar with Cocoon, another 20 to 30 days. And, we
are not sure if this enough time to have a clean codebase at the end.
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.
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)
. 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
. 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.
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.
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?
Any feedback is highly appreciated!
[1]
http://svn.apache.org/repos/asf/cocoon/whiteboard/micro/misc/cocoon-micro-it-block/src/main/resources/COB-INF/sitemap.xmap
[2] http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-it-fw/
Consists of two parts: (1) HTMLUnit tests + XPath assertions based on the
integration test framework of 2.1.x and (2) a Maven plugin that starts and
stops Jetty.
[3]
http://svn.apache.org/repos/asf/cocoon/whiteboard/micro/misc/cocoon-webapp/src/test/java/org/apache/cocoon/micro/it/
[4] http://people.apache.org/~reinhard/micro-cocoon-cobertura-report/
[5]
http://svn.apache.org/repos/asf/excalibur/trunk/components/sourceresolve/jnet/
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
Re: Micro-Cocoon ... Corona
On Mar 13, 2008, at 11:40 AM, Reinhard Poetz wrote: . a pipeline API (that isn't limited to XML pipelines but would also support connecting of any types of pipes) . 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 Speaking of which, I had intention to make a clear separation between pipeline assembly stage - which is currently done by tree processor - and pipeline execution stage - which is currently sometimes is done from within tree processor itself, in case of 'external pipelines', or out of tree processor for 'internal pipelines'. I have done a prototype work - and had it working after ~ 1 day effort. But I noticed that you went in complete opposite direction and were bundling the two stages together in 'micro cocoon'. So what are your thoughts on this one? Vadim
Re: Micro-Cocoon ... Corona
Reinhard Poetz wrote: In order to make sure that we don't break any functionality that we want to keep working, I wrote integration tests (see [1] for the sitemap and [2] for the integration test framework and [3] for the tests) which we let run whenever we changed something. This also gave us the chance to use Cobertura to find out how many lines of Cocoon code are actually needed to make the tests run. The (for me) surprising result was that of 23581 lines of code in Cocoon core, only 5510 are needed for the test cases. See [4] for the full reports. Interesting :) At the end of the third day we began to disucss how much work is still nessary in order to reach the goal of a light-weight Cocoon. Our estimation is that it will take somebody, who is familiar with Cocoon, another 20 to 30 days. And, we are not sure if this enough time to have a clean codebase at the end. 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. 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) Do you have use cases for this? (Just curious) . 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 Cool . 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. Ah, even cooler :) So far I haven't used JNet myself, so it seems you found it usefull. If there is anything missing/not working just let me know. 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. 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? If you don't mind, commit it to the whiteboard. I'm heavily interested in the stuff :) Carsten Any feedback is highly appreciated! [1] http://svn.apache.org/repos/asf/cocoon/whiteboard/micro/misc/cocoon-micro-it-block/src/main/resources/COB-INF/sitemap.xmap [2] http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-it-fw/ Consists of two parts: (1) HTMLUnit tests + XPath assertions based on the integration test framework of 2.1.x and (2) a Maven plugin that starts and stops Jetty. [3] http://svn.apache.org/repos/asf/cocoon/whiteboard/micro/misc/cocoon-webapp/src/test/java/org/apache/cocoon/micro/it/ [4] http://people.apache.org/~reinhard/micro-cocoon-cobertura-report/ [5] http://svn.apache.org/repos/asf/excalibur/trunk/components/sourceresolve/jnet/ -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Micro-Cocoon ... Corona
On 13.03.2008, at 18:11, Vadim Gritsenko wrote: On Mar 13, 2008, at 11:40 AM, Reinhard Poetz wrote: . a pipeline API (that isn't limited to XML pipelines but would also support connecting of any types of pipes) . 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 Speaking of which, I had intention to make a clear separation between pipeline assembly stage - which is currently done by tree processor - and pipeline execution stage - which is currently sometimes is done from within tree processor itself, in case of 'external pipelines', or out of tree processor for 'internal pipelines'. I have done a prototype work - and had it working after ~ 1 day effort. When we had the whole 'cocoon is dead - let's rewrite it' discussion that was exactly one of the thing I was thinking of. To some extend the sitemap should be just a factory creating pipelines. The pipelines should be a completely separate stand alone API that is just used by the sitemap. cheers -- Torsten
Re: Micro-Cocoon ... Corona
Torsten Curdt wrote:
On 13.03.2008, at 18:11, Vadim Gritsenko wrote:
On Mar 13, 2008, at 11:40 AM, Reinhard Poetz wrote:
. a pipeline API (that isn't limited to XML pipelines but would also
support connecting of any types of pipes)
. 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
Speaking of which, I had intention to make a clear separation between
pipeline assembly stage - which is currently done by tree processor -
and pipeline execution stage - which is currently sometimes is done
from within tree processor itself, in case of 'external pipelines', or
out of tree processor for 'internal pipelines'. I have done a
prototype work - and had it working after ~ 1 day effort.
When we had the whole 'cocoon is dead - let's rewrite it' discussion
that was exactly one of the thing I was thinking of. To some extend the
sitemap should be just a factory creating pipelines. The pipelines
should be a completely separate stand alone API that is just used by the
sitemap.
yes, that's the approach that we follow with Corona.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Micro-Cocoon ... Corona
On Thu, Mar 13, 2008 at 10:40 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: Reinhard Poetz wrote: sniplots of cool stuff/snip 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? Very interested. I'd second throwing it into the white board if you're willing? -- Peter Hunsberger
Re: Micro-Cocoon ... Corona
Peter Hunsberger skrev: On Thu, Mar 13, 2008 at 10:40 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: Reinhard Poetz wrote: sniplots of cool stuff/snip 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? Very interested. I'd second throwing it into the white board if you're willing? +1! /Daniel
Re: Micro-Cocoon ... Corona
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
Re: Micro-Cocoon ... Corona
Grzegorz Kossakowski pisze: 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? Sorry, I meant here I second question of Carsten. -- Grzegorz
Re: Micro-Cocoon ... Corona
Carsten Ziegeler wrote: Reinhard Poetz wrote: 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) Do you have use cases for this? (Just curious) I can think of a lot of them. Any time you want to make replacements in text where the source is not XML this could be useful. How about replacing property keys with property values, just as an obvious example. Or translating a text file to another language by looking up phrases in a resource bundle. Sure, you could use a templating engine, but that may be overkill for some applications and besides, suppose you wanted to do several unrelated replacements that used different kinds of templates? Or suppose you wanted to make changes to HTML generated by some other website that doesn't generate XHTML or even very sensible HTML? There are many reasons you might want to do this: to extract a bit of content from the page, to filter certain words, to alter URLs. I wrote a spider once that archived the state of a web application as of a certain day. It crawled web pages and replaced URLs with file: URLs that pointed to where the web page was stored locally. This was complicated by the fact that many web pages with the same URL would display different data depending on request parameters, and so had to be stored in different places but still be pointed to by the links if you followed a particular path through the stored HTML files. This was only one of many cleanups I needed to make to the archived HTML. Cocoon didn't help me because there was no reasonable way to get the HTML into XHTML. A non-XML pipeline would have helped a lot.
Re: Micro-Cocoon ... Corona
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
