cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon 2.0: proposed battleplan
Date Sat, 08 Apr 2000 23:49:48 GMT
Pierpaolo Fumagalli wrote:
> 
> 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 :)
> 
>     Pier
> 
> 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)

Should we target for Servlet 2.2?

>    - Better handling of engine creation, errors ...
> 
> C) Offline/Caching Functionality:
>    - Write it :)

Arkin volunteered to help designing and coding the cache system. Could
you check real-life with him for that?
 
> 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)
     - Transformer (think it as a TRaX adapter)

The above because other components (read XSP) need the instance an XSLt
transformer, that you can't make available if you create it as a filter
rather than a component.

> 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)

I would just have an XSLT filter that asks for the "transformer"
component and uses that. So whatever XSLT processor you want Cocoon to
use, it will be used thru-out its scope.

>    - XSP Taglib Filter
> 
> E) Serializers:
>    - XML bare serializer
>    - HTML bare serializer
>    - TEXT bare serializer
>    - TRAX serializers (again using TRAX as the pluggability API)

You already get the first three with the forth.

>    - 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
>                serializer?"
> 
> - 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"

I would add:

  - FOP
      Stefano said: "let's use it for both FO and SVG rendering
capabilities"

  - Page autofragmentation (more on this right next)
 
> >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?

I love this... let's create the "battleplan" design pattern and make it
like the Apache STATUS file. Great job Pier!

Should we XML-ize it so that we can render it on the site?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message