cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Battleplan?
Date Wed, 14 Jun 2000 23:27:19 GMT
Giacomo Pati wrote:
> 
> --- Ross Burton <ross.burton@mail.com> wrote:
> > 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.
> 
> Yup.
> 
> > However, the engine needs a rewrite due to the new sitemap.  Is the sitemap
> > schema finalised?
> 
> I wanted to implement the stable part of it but discussion about those sitemap parts
has been
> flamed up again. So I'm on stand by until there has be reached a consensus :(

I'll summarize the sitemap status so we can move on. this admittedly the
bottleneck right now...
 
> >
> > > 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.
> 
> Yes, that's what I've remembered also. But I didn't remember who is in charge of that.

I was, but you can't do this before finalizing the sitemap. The sitemap
has a lock on this. We must agree on the sitemap schema before moving on
since the offline part should use the sitemap information as well.
 
> >
> > > 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.
> 
> As we come to the conclusion to support only SAX/DOM 2 are those SAX1->SAX2 adaptors
still
> necessary?

I'd say, let's blast them: nobody wrote complex SAX1 legacy applications
anyway.
 
> > > 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.

I'd like to port the Cocoon1 cache (which is pretty good) over. Any
volunteer will be really appreciated.

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

Ok, agreed.

> > > 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.
> 
> Whats a HTTPGenerator?
> 
> >
> > > 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?
> 
> I do not have any experience with TRaX. The site mentioned version 0.6 still alpha but
cocoon 2
> still alpha, too, so, should we go that way?
> 
> >
> > > 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.
> 
> Yes, and have a status page which states Who works on What and how's the status of the
work.

The Todo DTD has already a "assigned" attribute. It was written exactly
for that and is automatically processed in the docs (even if the site
uses the main branch to create the HTML and this won't show up... anyway
CVS is good enough for all of us involved, I think)

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