Re: [STATUS] Cocoon Roadmap
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-devm=101169776323572w=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
[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
