cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <>
Subject Cocoon 2.0: proposed battleplan
Date Sat, 08 Apr 2000 21:27:53 GMT

Ok kids... Since I've seen no -1 to my suicidal decision to "take over"
this project :) and, actually, I got a lot of feedback on that, here's
the "battle plan" for the next release of Cocoon 2.0

Please comment, add, modify, revise, do whatever you want with this, and
say if you're interested in taking care of a certain part (and if you
have time :)


Cocoon 2.0 Beta Battle Plan (Deadline: JavaONE 2000)

The first things to define are what components are going to be
integrated into the "standard" Cocoon distribution, and so need to be
ready for the release, and wich ones are to be considered as "addition"
or plug-ins, and so can go on with proprietary schedules.

The components I think will be required in the Cocoon 2.0 beta release
are (merging what came out of the mailing list):

A) Engine:
   - Completion/cleanup of the engine interfaces
   - Cleanup of the sitemap code, with better (fixed) support for URI
     matching and rewriting
   - Review of the whole org.apache.arch.* packages and synchronization
     with the main Avalon/James trunk
   - Enable dynamic generator compilation loading

B) HTTP Servlet:
   - Better integration with Tomcat/Servlet 2.x (with x>0)
   - Better handling of engine creation, errors ...

C) Offline/Caching Functionality:
   - Write it :)

D) XML Utilities:
   - Double, triple check compliance and conformance of all XML utils
     expecially those converting from SAX->DOM and adapting SAX1->SAX2.

E) Root components:
   - Object Store: define better the interface and implement it so that
     we can keep instances of stored objects between restarts
   - Cache Manager: do something :)
   - Parser (we should need to write a JAXP adapter - kinda easy)

F) Generators:
   - File/URL generator (ParserGenerator)
   - XSP (or better dynamic generator creation/loading)

G) Filters:
   - XSLT Filter (based on XALAN)
   - TRAX Filter (used as a pluggability API, TRAX can access different
     filters, depending on the configuration)
   - XSP Taglib Filter

E) Serializers:
   - XML bare serializer
   - HTML bare serializer
   - TEXT bare serializer
   - TRAX serializers (again using TRAX as the pluggability API)
   - Java Bytecode Serializer (that's scary!)

F) Documentation:
   - Internal architecture description (basic concepts to allow other
     implementors to understand how components should be developed)
   - Installation HOWTO
   - Sitemap HOWTO (can this be integrated into the Installation HOWTO?)
   - XSP manual

Other components that are scheduled to be "plug ins" are (names are 
the ones associated with the person who proposed the addition):

- Printing (Ugo Corda)
    Pier said: "That's a hell-a-good idea... I'd like to investigate
               further on it. Can it be done as a filter nesting a

- Oracle PLSQL Producer (Marcelo Ochoa)
    Stefano said: "Can this be generic enough or it will be always tied
                  only to Oracle?"
- Turbine-Like Generator: (Giacomo Pati) 
    Still need some feedback on this.

- XForms (Gerard van Enk)
    Geremy said: "Maybe this should developed as a taglib"
    Pier said: "I roughly looked at the spec, but I really don't
               understand what we should do to make those work (what do
               you want to do with the data obtained from the form?)"

- XLink (Gerard van Enk)
    Pier said: "I don't see how XLink can work on the server side"

>From next week (tue), I'll start taking care of A, while I'm trying to
get a hold on C. Now, it's all up to you. How does this all sound?

	Pier (offline for most part of the weekend)

pier: stable structure erected over water to allow docking of seacraft
<>      <>

View raw message