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