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 [EMAIL PROTECTED], 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. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
