You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/03/02 11:47:56 UTC
[STATUS] Cocoon Roadmap
People,
I know some of you are discouradged by the lack of overall 'polishness'
of the latest and greatest version of Cocoon.
I think I can speak for the entire development community if I greatly
apologize for that. And I think you deserve it.
Yes, we are all volunteers, but one way or another, we are earning
something from this (if ever, visibility, respect and, last but not
least, fun and knowledge) and we must continue the level of the past
quality of our work in order to keep things going and to keep things
sane.
In this regard, I want to tell you a few things that are going on:
1) DOCUMENTATION: the documentation has been cleaned up a little, the
stylesheets of the web site polished to look much more readable and
light. Some documents were removed because we plan to incorporate more
stuff into that.
In this regard, please, help us making this better!
The reason why documentation is normally not that good is that we
generally don't need it since we can look into the code (which is the
best documentation, if you know where to look) or simply email the guy
who wrote it.
But this doesn't scale: documentation is the only way to make knowledge
scale well.
So, if you have *any* kind of notes, mockups, emails-to-your-boss,
courses you made to your colleagues, about cocoon and friends, please,
let us know! It doesn't matter if they are not formatted properly, if
they are not using our Documentation DTD or anything, don't worry, go to
bugzilla (http://nagoya.apache.org) and throw it into the PATCH queue,
somebody will pick it up, refactor it, place in into the docs and, most
important, *give you credits for it*!
It's *that* easy, believe me.
Doesn't matter if you think you don't know enough: it's *exactly*
because you don't feel like a guru (yet!) that your opinions, views,
input is important to all the other people that haven't finished
climbing the 'unfortunately steep' Cocoon learning curve :/
2) SPEED: we are currently *very* close in having Xalan XSLTC working
for Cocoon. XSLTC is a new XSLT processor that was donated to Apache by
Sun Microsytems and, just like XSP, transforms a stylesheet into
bytecode.
Tests on my machine show 600% speed improvement over Xalan-J!!! And 200%
speed improvement over MSXML (the native library that powers Internet
Explorer)!!!
along with an incredibly lower memory footprint (thus, reduced garbage
collection, and overall improved performance and scalability)
There are a few compliance bugs to sort out, but we are confident that
we'll be able to ship Cocoon with XSLTC in the near future (if not in
2.0.2, for sure in 2.0.3)
At the same time, we are looking into faster and more scalable ways to
store the cached files.
With these two things together, Cocoon might be able to increase
performance in the next couple of releases between 200% and 600%
(depending on your use of XSLT and cache, of course). We are very
excited about this.
Another issue what we are working on is the sitemap interpretation vs.
compilation: we currently have two engines for the sitemap, the one
based on XSLT-generated code and then compiled (the one you are using
right now) and a new interpreted-based one.
We believe that with Hotspot server JVMs, the interpreted version might
be faster, but we don't have numbers to show that today. For sure,
sitemap reload time is almost instant now, compared to the compiled
solution. And this is very nice for development cycles.
I expect the interpreted sitemap engine to be shipped very soon,
probably already in 2.0.2.
3) SYMMETRY: the cocoon devs have always been aware of the intrinsic
cocoon asymmetry between content flowing out and content flowing in.
There are number of things that we are working on in this regard:
3.1) Writeable Sources: we are working on making the protocol handlers
symmetrical, meaning that you can read from any resource (say
dbxml://database/docs/news) and also *write* on it. (this should remove
the need to create custom write-somewhere transformers for each type of
resource being used to write on)
3.2) Drains: there has been discussions about making possible to use
serializers to send content into those writeable sources (a.k.a. known
as 'drains', easier to understand for those of us with an electronical
background). Nothing has been resolved yet on this regard, but
discussions continue. Note that this might require back-incompatible
changes to the Serializer interface.
3.3) Pipe-aware selection: it has been proposed that if Selectors had a
way to look into the content on the pipeline, it would be much easier to
reuse shipped pipeline components instead of having to write custom
actions to take care of the 'updated stream'. This might also allow a
simpler implementation of WebDAV on top of Cocoon, but might require a
back-incompatible change to the Selector interface.
I would personally expect 3.1) to appear soon in the 2.0.x series. For
3.2) and 3.3) there is still lots of design work to do, so it won't be
before the 2.1.x series (expecially because of the possible
back-incompatible changes to the main interfaces).
4) APPLICATION MODULARITY: the Cocoon system is a highly modular
architecture heavily influenced by the component-oriented approach
designed in the Avalon project (http://jakarta.apache.org/avalon/).
Unfortunately, this can't be said for the 'application layer' on top of
Cocoon, where it looks much more similar to a single *huge* servlet,
than to a publishing framework. We want this to change, we want to make
it easy to package your cocoon web applications and *deploy* them easily
on Cocoon.
This is possible today by placing things in the
[tomcat_home]/webapps/cocoon/mount directory after your cocoon.war has
been deployed, but it's hack and work *only* if you don't have your own
java components or libraries to install.
In the future, it will be possible to package your own stuff (along with
your actions, your .jar libraries and every other resource you need) in
a single archive and *mount* it on top of Cocoon. We'll probably also
create a web interface (don't worry, it will be turned off by default to
avoid security holes!) for this to make it easier for you to deploy your
own cocoon additions, without having to recreate the cocoon.war
everytime.
Following the Avalon patterns, we are calling these packages "Cocoon
Blocks" and, unlike the Servlet API where packages are just dummy
containers and webapps are isolated, 'Cocoon Blocks' will probably have
a polymorphic behavior and will be possible to make them interoperate
between each other.
For example, in your 'main' cocoon block, you might have something like
this:
<map:match patter="news/**">
<map:generate src="{1}.xml"/>
<map:transform src="block[skin]:/xslt/news2html.xslt"/>
<map:serialize/>
</map:match>
where
block[skin]:/news2html.xslt
indicates that you want the file named 'news2html.xslt' located in the
'/xslt/' directory of the cocoon block that *implements* the *interface*
'skin' for that installation.
This would be equivalent of the java code:
Skin skin = (Skin) blockManager.getBlock(Skin.ROLE);
File file = skin.getFile("/xslt/news2html.xslt");
Each 'block' will have a deployment descriptor that indicates its role
(probably identified by a namespace-like URI, to avoid naming
collisions), thus the interface it implements, and will provide
indication on what other blocks it is expecting to be installed in the
system.
With this dependency of roles, it would be possible to write an
'apt-get'-like block installer that is capable of connection to a
central repository of blocks and give you proper choice when installing
your own stuff.
I'm the person that proposed the above solution and I'm *very*
interested in making it work ASAP, after all the design details are
worked out, but reasonably, don't expect this before 2.1.x
4) FLOWMAPS
Another big asymmetry in current Cocoon architecture is the fact that
the sitemap semantics are heavily declarative and inherently stateless.
While this is very nice for web publishing, is somewhat less useful for
web applications because forces you to write a finite-state-machine-like
description of states and transitions where the 'flow' of your
application is scattered around the entire site description.
This is not a problem if the transitions are very free-form and user
driven (like in a publishing-oriented web solution), but becomes one for
those solutions where is the web application that has to guide the user,
not the opposite.
In these circumstances, we believe it would be better to describe the
site in terms of a 'flowmap'.
The flowmap syntax, unlike the sitemap where the XML syntax is a perfect
choice for its intrinsic declarativity, will use a
programming-language-like syntax since a flow is much more similar to a
program and will normally be written and managed by programmers which
are used to more 'procedural' approaches.
The flowmap will also be transparently stateful: writing a web
application that creates the sum of two numbers will be as easy as doing
var a = getA();
var b = getB();
c = a + b;
show(c);
the underlying implementation will allow Cocoon to know 'where you left
out' the execution of your program and restart from there. For those of
you with some assembly background, this is very similar to what happens
in a CPU when there is an interrupt: all data and the instruction
pointer are saved somewhere and execution is resurrected from where you
left, without loosing your data or your state.
This is what we think we are missing to add MVC to Cocoon: the flowmaps
will be the high-level controllers, glueing together business logic
contained in normal java classes (the flowmap will, of course, be able
to interface transparently with any java stuff), the views will be a
choice of JSP, XSP (with custom taglibs) and Velocity templates.
For more info, checkout the 'xml-cocoon2/src/scratchpad/schecoon' folder
into CVS.
I would love to be able to have this working for the 2.1.x series, but
in case we are a little late with the implementation, we should postpone
it to 2.2.x)
- o -
Uh, that was longer than I thought ;-)
As you see, there is lots of stuff we are working on and probably
something where you might help, even by critizicing.
One thing: all development happens at cocoon-dev@xml.apache.org, so if
you are interested in any of the above stuff and want to help, even by
only stating your opinion or simple appreciation, join our fun there.
For those of you who badly need the features I explained 'yesterday',
well, you're not the only one, believe me and any possible help will be
much appreciated.
Thanks for reaching this far.
Keep it up!
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] Cocoon Roadmap
Posted by MJ Ray <ma...@cloaked.freeserve.co.uk>.
Sylvain Wallez wrote:
> To make things easier for those who want to write with our document DTD,
> I've written a CSS2 stylesheet for it. I tested it with the XMLmind XML
> editor (aka XXE, see http://www.xmlmind.com/xmleditor/) : it's a cool
> open-source CSS2 enabled XML editor written in Java, which provides
> word-processor like document editing.
I've not checked in absolute detail, but it looks like the restrictions on
the licence mean that it is not Free Software, nor even "open source" by
OSI's definition of it. (For example, you may not modify it to add new
features, or redistribute it or patches for it.) Please be careful calling
things "open source" and about things called "open source", as the meaning
of that term is rather unclear.
Sorry for wandering OT, but I spotted that while compiling the next
Cocoon-URL.
--
MJR ,----------------------------------------------------
| Q. Do you need a net-based application developing,
| or advice and training about web technology?
| A. I suggest you try http://www.luminas.co.uk/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] Cocoon Roadmap
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
>
> Stefano Mazzocchi wrote:
>
> >People,
> >
> >I know some of you are discouradged by the lack of overall 'polishness'
> >of the latest and greatest version of Cocoon.
> >
> >I think I can speak for the entire development community if I greatly
> >apologize for that. And I think you deserve it.
> >
> >Yes, we are all volunteers, but one way or another, we are earning
> >something from this (if ever, visibility, respect and, last but not
> >least, fun and knowledge) and we must continue the level of the past
> >quality of our work in order to keep things going and to keep things
> >sane.
> >
> >In this regard, I want to tell you a few things that are going on:
> >
> >1) DOCUMENTATION: the documentation has been cleaned up a little, the
> >stylesheets of the web site polished to look much more readable and
> >light. Some documents were removed because we plan to incorporate more
> >stuff into that.
> >
> >In this regard, please, help us making this better!
> >
> >The reason why documentation is normally not that good is that we
> >generally don't need it since we can look into the code (which is the
> >best documentation, if you know where to look) or simply email the guy
> >who wrote it.
> >
> >But this doesn't scale: documentation is the only way to make knowledge
> >scale well.
> >
> >So, if you have *any* kind of notes, mockups, emails-to-your-boss,
> >courses you made to your colleagues, about cocoon and friends, please,
> >let us know! It doesn't matter if they are not formatted properly, if
> >they are not using our Documentation DTD or anything, don't worry, go to
> >bugzilla (http://nagoya.apache.org) and throw it into the PATCH queue,
> >somebody will pick it up, refactor it, place in into the docs and, most
> >important, *give you credits for it*!
> >
> >It's *that* easy, believe me.
> >
> To make things easier for those who want to write with our document DTD,
> I've written a CSS2 stylesheet for it. I tested it with the XMLmind XML
> editor (aka XXE, see http://www.xmlmind.com/xmleditor/) : it's a cool
> open-source CSS2 enabled XML editor written in Java, which provides
> word-processor like document editing.
>
> Since the CSS renders like the web site, writing a doc in the document
> DTD is like writing a web page ! Check it out in
> src/documentation/xdocs/css, and be indulgent since it's my first CSS2
> stylesheet :)
Oh, way cool, I'll check this out right away!
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] Cocoon Roadmap
Posted by Torsten Curdt <tc...@dff.st>.
> >>>I expect the interpreted sitemap engine to be shipped very soon,
> >>>probably already in 2.0.2.
> >>>
> >>So, if nobody objects, I'll move it to the main trunk for 2.0.2.
> >>
> >I thought we already voted and there were no objections...
> >so at least I would say: go ahead :)
> >
> Yes, we voted, but Vadim asked to leave it in scratchpad until 2.0.2
> gets out. That's what it was all about...
IIRC we aggreed on moving it from the scratchpad into the main trunk
...but keep the compiled sitemap as default in the cocoon.xconf
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] Cocoon Roadmap
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Torsten Curdt wrote:
>On Sun, 3 Mar 2002, Sylvain Wallez wrote:
>
>>>I expect the interpreted sitemap engine to be shipped very soon,
>>>probably already in 2.0.2.
>>>
>>So, if nobody objects, I'll move it to the main trunk for 2.0.2.
>>
>I thought we already voted and there were no objections...
>so at least I would say: go ahead :)
>
Yes, we voted, but Vadim asked to leave it in scratchpad until 2.0.2
gets out. That's what it was all about...
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Move TreeProcessor to main trunk (was RE: [STATUS] Cocoon Roadmap)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
+1
Hey, what are we waiting? ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE] Move TreeProcessor to main trunk (was RE: [STATUS] Cocoon Roadmap)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> Berin Loritsch wrote:
>
> > Davanum Srinivas wrote:
> >
> >> +1 to move treeprocessor from scratchpad into the main trunk ASAP.
> >>
> >> Thanks,
> >> dims
> >
> > +1
>
> Ok, ok, no need for a second vote ! I'll move it ASAP !!
>
+1 :P
Vadim
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies Apache Cocoon
> http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Move TreeProcessor to main trunk (was RE: [STATUS] Cocoon Roadmap)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch wrote:
> Davanum Srinivas wrote:
>
>> +1 to move treeprocessor from scratchpad into the main trunk ASAP.
>>
>> Thanks,
>> dims
>
> +1
Ok, ok, no need for a second vote ! I'll move it ASAP !!
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Move TreeProcessor to main trunk (was RE: [STATUS] Cocoon Roadmap)
Posted by Berin Loritsch <bl...@apache.org>.
Davanum Srinivas wrote:
> +1 to move treeprocessor from scratchpad into the main trunk ASAP.
>
> Thanks,
> dims
+1
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[VOTE] Move TreeProcessor to main trunk (was RE: [STATUS] Cocoon Roadmap)
Posted by Davanum Srinivas <di...@yahoo.com>.
+1 to move treeprocessor from scratchpad into the main trunk ASAP.
Thanks,
dims
--- giacomo <gi...@apache.org> wrote:
> On Mon, 4 Mar 2002, Torsten Curdt wrote:
>
> > On Sun, 3 Mar 2002, Sylvain Wallez wrote:
> > > >I expect the interpreted sitemap engine to be shipped very soon,
> > > >probably already in 2.0.2.
> > > >
> > > So, if nobody objects, I'll move it to the main trunk for 2.0.2.
> >
> > I thought we already voted and there were no objections...
> > so at least I would say: go ahead :)
>
> BTW: I have an app working for about a month with the treeprocessor in a
> production environment without any problems. So +1 on moving it from
> the scratchpad into the main trunk ASAP.
>
> Giacomo
>
> >
> > > <snip what="many interesting stuff"/>
> >
> > ...exactly - more to come :)
> > --
> > Torsten
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas - http://xml.apache.org/~dims/
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] Cocoon Roadmap
Posted by giacomo <gi...@apache.org>.
On Mon, 4 Mar 2002, Torsten Curdt wrote:
> On Sun, 3 Mar 2002, Sylvain Wallez wrote:
> > >I expect the interpreted sitemap engine to be shipped very soon,
> > >probably already in 2.0.2.
> > >
> > So, if nobody objects, I'll move it to the main trunk for 2.0.2.
>
> I thought we already voted and there were no objections...
> so at least I would say: go ahead :)
BTW: I have an app working for about a month with the treeprocessor in a
production environment without any problems. So +1 on moving it from
the scratchpad into the main trunk ASAP.
Giacomo
>
> > <snip what="many interesting stuff"/>
>
> ...exactly - more to come :)
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] Cocoon Roadmap
Posted by Torsten Curdt <tc...@dff.st>.
On Sun, 3 Mar 2002, Sylvain Wallez wrote:
> >I expect the interpreted sitemap engine to be shipped very soon,
> >probably already in 2.0.2.
> >
> So, if nobody objects, I'll move it to the main trunk for 2.0.2.
I thought we already voted and there were no objections...
so at least I would say: go ahead :)
> <snip what="many interesting stuff"/>
...exactly - more to come :)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] Cocoon Roadmap
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>People,
>
>I know some of you are discouradged by the lack of overall 'polishness'
>of the latest and greatest version of Cocoon.
>
>I think I can speak for the entire development community if I greatly
>apologize for that. And I think you deserve it.
>
>Yes, we are all volunteers, but one way or another, we are earning
>something from this (if ever, visibility, respect and, last but not
>least, fun and knowledge) and we must continue the level of the past
>quality of our work in order to keep things going and to keep things
>sane.
>
>In this regard, I want to tell you a few things that are going on:
>
>1) DOCUMENTATION: the documentation has been cleaned up a little, the
>stylesheets of the web site polished to look much more readable and
>light. Some documents were removed because we plan to incorporate more
>stuff into that.
>
>In this regard, please, help us making this better!
>
>The reason why documentation is normally not that good is that we
>generally don't need it since we can look into the code (which is the
>best documentation, if you know where to look) or simply email the guy
>who wrote it.
>
>But this doesn't scale: documentation is the only way to make knowledge
>scale well.
>
>So, if you have *any* kind of notes, mockups, emails-to-your-boss,
>courses you made to your colleagues, about cocoon and friends, please,
>let us know! It doesn't matter if they are not formatted properly, if
>they are not using our Documentation DTD or anything, don't worry, go to
>bugzilla (http://nagoya.apache.org) and throw it into the PATCH queue,
>somebody will pick it up, refactor it, place in into the docs and, most
>important, *give you credits for it*!
>
>It's *that* easy, believe me.
>
To make things easier for those who want to write with our document DTD,
I've written a CSS2 stylesheet for it. I tested it with the XMLmind XML
editor (aka XXE, see http://www.xmlmind.com/xmleditor/) : it's a cool
open-source CSS2 enabled XML editor written in Java, which provides
word-processor like document editing.
Since the CSS renders like the web site, writing a doc in the document
DTD is like writing a web page ! Check it out in
src/documentation/xdocs/css, and be indulgent since it's my first CSS2
stylesheet :)
<snip/>
>Doesn't matter if you think you don't know enough: it's *exactly*
>because you don't feel like a guru (yet!) that your opinions, views,
>input is important to all the other people that haven't finished
>climbing the 'unfortunately steep' Cocoon learning curve :/
>
>2) SPEED: we are currently *very* close in having Xalan XSLTC working
>for Cocoon. XSLTC is a new XSLT processor that was donated to Apache by
>Sun Microsytems and, just like XSP, transforms a stylesheet into
>bytecode.
>
>Tests on my machine show 600% speed improvement over Xalan-J!!! And 200%
>speed improvement over MSXML (the native library that powers Internet
>Explorer)!!!
>
That's sooo great : no, Java isn't slow !
>along with an incredibly lower memory footprint (thus, reduced garbage
>collection, and overall improved performance and scalability)
>
>There are a few compliance bugs to sort out, but we are confident that
>we'll be able to ship Cocoon with XSLTC in the near future (if not in
>2.0.2, for sure in 2.0.3)
>
>At the same time, we are looking into faster and more scalable ways to
>store the cached files.
>
>With these two things together, Cocoon might be able to increase
>performance in the next couple of releases between 200% and 600%
>(depending on your use of XSLT and cache, of course). We are very
>excited about this.
>
>Another issue what we are working on is the sitemap interpretation vs.
>compilation: we currently have two engines for the sitemap, the one
>based on XSLT-generated code and then compiled (the one you are using
>right now) and a new interpreted-based one.
>
>We believe that with Hotspot server JVMs, the interpreted version might
>be faster, but we don't have numbers to show that today. For sure,
>sitemap reload time is almost instant now, compared to the compiled
>solution. And this is very nice for development cycles.
>
Quick tests showed that request processing can be up to 10% faster than
with the compiled engine (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101169776323572&w=4 ).
>I expect the interpreted sitemap engine to be shipped very soon,
>probably already in 2.0.2.
>
So, if nobody objects, I'll move it to the main trunk for 2.0.2.
>3) SYMMETRY: the cocoon devs have always been aware of the intrinsic
>cocoon asymmetry between content flowing out and content flowing in.
>
>There are number of things that we are working on in this regard:
>
> 3.1) Writeable Sources: we are working on making the protocol handlers
>symmetrical, meaning that you can read from any resource (say
>dbxml://database/docs/news) and also *write* on it. (this should remove
>the need to create custom write-somewhere transformers for each type of
>resource being used to write on)
>
This is a reality with the latest CVS for files (using the 'file:'
protocol). Writing can also be transactional : see FileSource
implementation that uses a temp file until closed sucessfully. The next
two sources that should be made writeable are xmldb and raw URLs
(allowing http or ftp upload)
<snip what="many interesting stuff"/>
>
>Thanks for reaching this far.
>
I did ;)
>Keep it up!
>
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: [STATUS] Cocoon Roadmap
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
What about adding a 'What's new' on Cocoon site and place this kind of stuff
there too?
Regards,
Konstantin Piroumian
> People,
>
> I know some of you are discouradged by the lack of overall 'polishness'
> of the latest and greatest version of Cocoon.
>
> I think I can speak for the entire development community if I greatly
> apologize for that. And I think you deserve it.
>
> Yes, we are all volunteers, but one way or another, we are earning
> something from this (if ever, visibility, respect and, last but not
> least, fun and knowledge) and we must continue the level of the past
> quality of our work in order to keep things going and to keep things
> sane.
>
> In this regard, I want to tell you a few things that are going on:
>
> 1) DOCUMENTATION: the documentation has been cleaned up a little, the
> stylesheets of the web site polished to look much more readable and
> light. Some documents were removed because we plan to incorporate more
> stuff into that.
>
> In this regard, please, help us making this better!
>
> The reason why documentation is normally not that good is that we
> generally don't need it since we can look into the code (which is the
> best documentation, if you know where to look) or simply email the guy
> who wrote it.
>
> But this doesn't scale: documentation is the only way to make knowledge
> scale well.
>
> So, if you have *any* kind of notes, mockups, emails-to-your-boss,
> courses you made to your colleagues, about cocoon and friends, please,
> let us know! It doesn't matter if they are not formatted properly, if
> they are not using our Documentation DTD or anything, don't worry, go to
> bugzilla (http://nagoya.apache.org) and throw it into the PATCH queue,
> somebody will pick it up, refactor it, place in into the docs and, most
> important, *give you credits for it*!
>
> It's *that* easy, believe me.
>
> Doesn't matter if you think you don't know enough: it's *exactly*
> because you don't feel like a guru (yet!) that your opinions, views,
> input is important to all the other people that haven't finished
> climbing the 'unfortunately steep' Cocoon learning curve :/
>
> 2) SPEED: we are currently *very* close in having Xalan XSLTC working
> for Cocoon. XSLTC is a new XSLT processor that was donated to Apache by
> Sun Microsytems and, just like XSP, transforms a stylesheet into
> bytecode.
>
> Tests on my machine show 600% speed improvement over Xalan-J!!! And 200%
> speed improvement over MSXML (the native library that powers Internet
> Explorer)!!!
>
> along with an incredibly lower memory footprint (thus, reduced garbage
> collection, and overall improved performance and scalability)
>
> There are a few compliance bugs to sort out, but we are confident that
> we'll be able to ship Cocoon with XSLTC in the near future (if not in
> 2.0.2, for sure in 2.0.3)
>
> At the same time, we are looking into faster and more scalable ways to
> store the cached files.
>
> With these two things together, Cocoon might be able to increase
> performance in the next couple of releases between 200% and 600%
> (depending on your use of XSLT and cache, of course). We are very
> excited about this.
>
> Another issue what we are working on is the sitemap interpretation vs.
> compilation: we currently have two engines for the sitemap, the one
> based on XSLT-generated code and then compiled (the one you are using
> right now) and a new interpreted-based one.
>
> We believe that with Hotspot server JVMs, the interpreted version might
> be faster, but we don't have numbers to show that today. For sure,
> sitemap reload time is almost instant now, compared to the compiled
> solution. And this is very nice for development cycles.
>
> I expect the interpreted sitemap engine to be shipped very soon,
> probably already in 2.0.2.
>
> 3) SYMMETRY: the cocoon devs have always been aware of the intrinsic
> cocoon asymmetry between content flowing out and content flowing in.
>
> There are number of things that we are working on in this regard:
>
> 3.1) Writeable Sources: we are working on making the protocol handlers
> symmetrical, meaning that you can read from any resource (say
> dbxml://database/docs/news) and also *write* on it. (this should remove
> the need to create custom write-somewhere transformers for each type of
> resource being used to write on)
>
> 3.2) Drains: there has been discussions about making possible to use
> serializers to send content into those writeable sources (a.k.a. known
> as 'drains', easier to understand for those of us with an electronical
> background). Nothing has been resolved yet on this regard, but
> discussions continue. Note that this might require back-incompatible
> changes to the Serializer interface.
>
> 3.3) Pipe-aware selection: it has been proposed that if Selectors had a
> way to look into the content on the pipeline, it would be much easier to
> reuse shipped pipeline components instead of having to write custom
> actions to take care of the 'updated stream'. This might also allow a
> simpler implementation of WebDAV on top of Cocoon, but might require a
> back-incompatible change to the Selector interface.
>
> I would personally expect 3.1) to appear soon in the 2.0.x series. For
> 3.2) and 3.3) there is still lots of design work to do, so it won't be
> before the 2.1.x series (expecially because of the possible
> back-incompatible changes to the main interfaces).
>
> 4) APPLICATION MODULARITY: the Cocoon system is a highly modular
> architecture heavily influenced by the component-oriented approach
> designed in the Avalon project (http://jakarta.apache.org/avalon/).
>
> Unfortunately, this can't be said for the 'application layer' on top of
> Cocoon, where it looks much more similar to a single *huge* servlet,
> than to a publishing framework. We want this to change, we want to make
> it easy to package your cocoon web applications and *deploy* them easily
> on Cocoon.
>
> This is possible today by placing things in the
> [tomcat_home]/webapps/cocoon/mount directory after your cocoon.war has
> been deployed, but it's hack and work *only* if you don't have your own
> java components or libraries to install.
>
> In the future, it will be possible to package your own stuff (along with
> your actions, your .jar libraries and every other resource you need) in
> a single archive and *mount* it on top of Cocoon. We'll probably also
> create a web interface (don't worry, it will be turned off by default to
> avoid security holes!) for this to make it easier for you to deploy your
> own cocoon additions, without having to recreate the cocoon.war
> everytime.
>
> Following the Avalon patterns, we are calling these packages "Cocoon
> Blocks" and, unlike the Servlet API where packages are just dummy
> containers and webapps are isolated, 'Cocoon Blocks' will probably have
> a polymorphic behavior and will be possible to make them interoperate
> between each other.
>
> For example, in your 'main' cocoon block, you might have something like
> this:
>
> <map:match patter="news/**">
> <map:generate src="{1}.xml"/>
> <map:transform src="block[skin]:/xslt/news2html.xslt"/>
> <map:serialize/>
> </map:match>
>
> where
>
> block[skin]:/news2html.xslt
>
> indicates that you want the file named 'news2html.xslt' located in the
> '/xslt/' directory of the cocoon block that *implements* the *interface*
> 'skin' for that installation.
>
> This would be equivalent of the java code:
>
> Skin skin = (Skin) blockManager.getBlock(Skin.ROLE);
> File file = skin.getFile("/xslt/news2html.xslt");
>
> Each 'block' will have a deployment descriptor that indicates its role
> (probably identified by a namespace-like URI, to avoid naming
> collisions), thus the interface it implements, and will provide
> indication on what other blocks it is expecting to be installed in the
> system.
>
> With this dependency of roles, it would be possible to write an
> 'apt-get'-like block installer that is capable of connection to a
> central repository of blocks and give you proper choice when installing
> your own stuff.
>
> I'm the person that proposed the above solution and I'm *very*
> interested in making it work ASAP, after all the design details are
> worked out, but reasonably, don't expect this before 2.1.x
>
> 4) FLOWMAPS
>
> Another big asymmetry in current Cocoon architecture is the fact that
> the sitemap semantics are heavily declarative and inherently stateless.
> While this is very nice for web publishing, is somewhat less useful for
> web applications because forces you to write a finite-state-machine-like
> description of states and transitions where the 'flow' of your
> application is scattered around the entire site description.
>
> This is not a problem if the transitions are very free-form and user
> driven (like in a publishing-oriented web solution), but becomes one for
> those solutions where is the web application that has to guide the user,
> not the opposite.
>
> In these circumstances, we believe it would be better to describe the
> site in terms of a 'flowmap'.
>
> The flowmap syntax, unlike the sitemap where the XML syntax is a perfect
> choice for its intrinsic declarativity, will use a
> programming-language-like syntax since a flow is much more similar to a
> program and will normally be written and managed by programmers which
> are used to more 'procedural' approaches.
>
> The flowmap will also be transparently stateful: writing a web
> application that creates the sum of two numbers will be as easy as doing
>
> var a = getA();
> var b = getB();
> c = a + b;
> show(c);
>
> the underlying implementation will allow Cocoon to know 'where you left
> out' the execution of your program and restart from there. For those of
> you with some assembly background, this is very similar to what happens
> in a CPU when there is an interrupt: all data and the instruction
> pointer are saved somewhere and execution is resurrected from where you
> left, without loosing your data or your state.
>
> This is what we think we are missing to add MVC to Cocoon: the flowmaps
> will be the high-level controllers, glueing together business logic
> contained in normal java classes (the flowmap will, of course, be able
> to interface transparently with any java stuff), the views will be a
> choice of JSP, XSP (with custom taglibs) and Velocity templates.
>
> For more info, checkout the 'xml-cocoon2/src/scratchpad/schecoon' folder
> into CVS.
>
> I would love to be able to have this working for the 2.1.x series, but
> in case we are a little late with the implementation, we should postpone
> it to 2.2.x)
>
> - o -
>
> Uh, that was longer than I thought ;-)
>
> As you see, there is lots of stuff we are working on and probably
> something where you might help, even by critizicing.
>
> One thing: all development happens at cocoon-dev@xml.apache.org, so if
> you are interested in any of the above stuff and want to help, even by
> only stating your opinion or simple appreciation, join our fun there.
>
> For those of you who badly need the features I explained 'yesterday',
> well, you're not the only one, believe me and any possible help will be
> much appreciated.
>
> Thanks for reaching this far.
>
> Keep it up!
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [STATUS] Cocoon Roadmap
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>People,
>
>I know some of you are discouradged by the lack of overall 'polishness'
>of the latest and greatest version of Cocoon.
>
>I think I can speak for the entire development community if I greatly
>apologize for that. And I think you deserve it.
>
>Yes, we are all volunteers, but one way or another, we are earning
>something from this (if ever, visibility, respect and, last but not
>least, fun and knowledge) and we must continue the level of the past
>quality of our work in order to keep things going and to keep things
>sane.
>
>In this regard, I want to tell you a few things that are going on:
>
>1) DOCUMENTATION: the documentation has been cleaned up a little, the
>stylesheets of the web site polished to look much more readable and
>light. Some documents were removed because we plan to incorporate more
>stuff into that.
>
>In this regard, please, help us making this better!
>
>The reason why documentation is normally not that good is that we
>generally don't need it since we can look into the code (which is the
>best documentation, if you know where to look) or simply email the guy
>who wrote it.
>
>But this doesn't scale: documentation is the only way to make knowledge
>scale well.
>
>So, if you have *any* kind of notes, mockups, emails-to-your-boss,
>courses you made to your colleagues, about cocoon and friends, please,
>let us know! It doesn't matter if they are not formatted properly, if
>they are not using our Documentation DTD or anything, don't worry, go to
>bugzilla (http://nagoya.apache.org) and throw it into the PATCH queue,
>somebody will pick it up, refactor it, place in into the docs and, most
>important, *give you credits for it*!
>
>It's *that* easy, believe me.
>
To make things easier for those who want to write with our document DTD,
I've written a CSS2 stylesheet for it. I tested it with the XMLmind XML
editor (aka XXE, see http://www.xmlmind.com/xmleditor/) : it's a cool
open-source CSS2 enabled XML editor written in Java, which provides
word-processor like document editing.
Since the CSS renders like the web site, writing a doc in the document
DTD is like writing a web page ! Check it out in
src/documentation/xdocs/css, and be indulgent since it's my first CSS2
stylesheet :)
<snip/>
>Doesn't matter if you think you don't know enough: it's *exactly*
>because you don't feel like a guru (yet!) that your opinions, views,
>input is important to all the other people that haven't finished
>climbing the 'unfortunately steep' Cocoon learning curve :/
>
>2) SPEED: we are currently *very* close in having Xalan XSLTC working
>for Cocoon. XSLTC is a new XSLT processor that was donated to Apache by
>Sun Microsytems and, just like XSP, transforms a stylesheet into
>bytecode.
>
>Tests on my machine show 600% speed improvement over Xalan-J!!! And 200%
>speed improvement over MSXML (the native library that powers Internet
>Explorer)!!!
>
That's sooo great : no, Java isn't slow !
>along with an incredibly lower memory footprint (thus, reduced garbage
>collection, and overall improved performance and scalability)
>
>There are a few compliance bugs to sort out, but we are confident that
>we'll be able to ship Cocoon with XSLTC in the near future (if not in
>2.0.2, for sure in 2.0.3)
>
>At the same time, we are looking into faster and more scalable ways to
>store the cached files.
>
>With these two things together, Cocoon might be able to increase
>performance in the next couple of releases between 200% and 600%
>(depending on your use of XSLT and cache, of course). We are very
>excited about this.
>
>Another issue what we are working on is the sitemap interpretation vs.
>compilation: we currently have two engines for the sitemap, the one
>based on XSLT-generated code and then compiled (the one you are using
>right now) and a new interpreted-based one.
>
>We believe that with Hotspot server JVMs, the interpreted version might
>be faster, but we don't have numbers to show that today. For sure,
>sitemap reload time is almost instant now, compared to the compiled
>solution. And this is very nice for development cycles.
>
Quick tests showed that request processing can be up to 10% faster than
with the compiled engine (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101169776323572&w=4 ).
>I expect the interpreted sitemap engine to be shipped very soon,
>probably already in 2.0.2.
>
So, if nobody objects, I'll move it to the main trunk for 2.0.2.
>3) SYMMETRY: the cocoon devs have always been aware of the intrinsic
>cocoon asymmetry between content flowing out and content flowing in.
>
>There are number of things that we are working on in this regard:
>
> 3.1) Writeable Sources: we are working on making the protocol handlers
>symmetrical, meaning that you can read from any resource (say
>dbxml://database/docs/news) and also *write* on it. (this should remove
>the need to create custom write-somewhere transformers for each type of
>resource being used to write on)
>
This is a reality with the latest CVS for files (using the 'file:'
protocol). Writing can also be transactional : see FileSource
implementation that uses a temp file until closed sucessfully. The next
two sources that should be made writeable are xmldb and raw URLs
(allowing http or ftp upload)
<snip what="many interesting stuff"/>
>
>Thanks for reaching this far.
>
I did ;)
>Keep it up!
>
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org