Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Date: Mon, 3 Jan 2000 15:45:10 -0500 (EST)
From: Donald Ball <balld@webslingerZ.com>
To: cocoon-dev@xml.apache.org
Subject: Re: Parallelizing Cocoon Development
In-Reply-To: <38635BFC.121C25B8@apache.org>
Message-ID: 
 <Pine.LNX.4.10.10001031538140.24292-100000@phoenix.webslingerZ.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 24 Dec 1999, Stefano Mazzocchi wrote:

> Donald Ball wrote:
> > +1 for cocoon-modules or cocoon-extra. Heck, I see rationale for moving
> > SQLProcessor and LDAPProcessor over there too. We can do releases of the
> > two repositories independently of one another, for one thing.
> 

[ ... interesting block pattern elaboration snipped ... ]

> Such a pattern allows you to update the box without requiring the rest
> of the application to be aware of it. In fact, the Block pattern
> includes information such as:
> 
>  - author
>  - version
>  - location where to find latest one
>  - problems
>  - configuration templates
> 
> Think at a parallel like this:
> 
>  a class is a lego brick
>  an interface is a lego brick shape (as pictured in the building
> instructions)
>  an application is the finished work
>  a block is a collection of bricks that doesn't do anything alone but
> can be used in many applications (such as engines or stearing wheel
> parts)
> 
> In Avalon we wanted to provide the ability for the application (which is
> a collection of blocks) to update itself, looking to the web for new
> bugfixes and prompting the administrator for what to do.
> Also, it should be able to download the required packages for you, or at
> least, tell you where to find them.
> 
> what do you think? (part of that is already implemented)

Sounds interesting. We seem to already have something along those lines
already working - e.g. any class that implements Configurable and
Processor and is mentioned in cocoon.properties as a processor can be
invoked as a processor, but the requesttime configuration is left
completely up to the processor. All well and good, but the question
remains - what do we do about the new modules that people are writing? We
don't want to bloat cocoon with all of them, because we don't really want
to tie cocoon's release cycle to the modules' release cycles and vice
versa (already have had this problem with SQLProcessor), but we do want to
make the modules easy to access (and provide web and cvs space for module
authors if they desire). So should we make a cocoon-modules module or put
the most commonly useful modules in cocoon and just provide some links to
the others from the cocoon webspace?

- donald