cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [STATUS] Cocoon Roadmap
Date Sat, 02 Mar 2002 10:47:56 GMT
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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message