cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Burton" <ross.bur...@mail.com>
Subject Battleplan?
Date Wed, 14 Jun 2000 08:55:49 GMT
Hi,

It seems to me that development on Cocoon 2 has stalled.  In an attempt to
stop this, I'm bringing up another battleplan.

This was Pier's battle plan in April:

> 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

The merging of the Avalon code is being looked at by Berin Loritsch.
However, the engine needs a rewrite due to the new sitemap.  Is the sitemap
schema finalised?

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

Boring but essential.

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

A patch exists but is due to be re-written using XLink (correct?).  Once the
new sitemap is up and running, this should be easier.

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

There are bugs in DOMBuilder (it breaks when a DTD is in the SAX stream).
DOM -> SAX seems to work however.

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

We have an object store from the XSP implementaion.  A cache is needed.

Ricardo was expressing a need for DOM methods in the parser -  I too would
like this as SVG is DOM based too.  At the moment I have to use Xerces, not
the abstraction.

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

XSP is done.  I have somewhere a minimal HTTPGenerator (it's about 5 lines)
which seems to work fine.  Really this should be generalised into a URL
Generator.

> 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

XSP and XSLT are done.  Does anybody know how TRAX is doing?

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

All of the above can be done using TRAX (except the bytecode one).  Status
on TRAX?

> 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

Well, we all hate docs so these can wait!  :-)

We need to consider how Cocoon 2 can be used from other applications.  Kevin
Burton (no relation!) is interested in using Cocoon 2 in JetSpeed, so he can
throw some input in there.

I'm working on SVG serializers and filters at the moment, but once they are
done I will do my best to chip away at the work to be done!

Let's build up a comprehensive todo list and stick it on the site - I'm sure
there is more to add here but I don't have the time now to dig through my
archive.

Comments?

Ross Burton

PROGRAM: n.  a magic spell cast over a computer allowing it to turn one's
input into error messages.  v.t.  to engage in a pastime similar to banging
one's head against a wall, but with fewer opportunities for reward.


Mime
View raw message