cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Parallelizing Cocoon Development
Date Mon, 03 Jan 2000 22:12:58 GMT
Donald Ball wrote:
> 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 as a processor can be
> invoked as a processor, but the requesttime configuration is left
> completely up to the processor. 

Yes, where do you think I got this pattern :) It was my early
contribution to Avalon.

> All well and good, but the question
> remains - what do we do about the new modules that people are writing? 

We create a cocoon module CPAN.

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

Ok, what about this: you access /Cocoon-modules.xml and a magic portal
to all of the available Cocoon modules appears to you. Then you can
download and install the modules you want, or, in case there is a new
version available, upgrade the one already installed.

What do you think?

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


But doing this directly thru Cocoon would simplify the
installation/management operations required, don't you think?

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message