cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject Re: Parallelizing Cocoon Development
Date Tue, 04 Jan 2000 06:45:46 GMT
On Mon, 3 Jan 2000, Stefano Mazzocchi wrote:

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

Sounds interesting, but I don't think it's going to be quite as seemless
and easy as you make it sound unless the user cocoon is running as has
permission to edit the servlet engine's classpath and/or cocoon's
configuration file... maybe if we had a command-line interface that
allowed this.

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

Uh, it was an either/or question, I thought... :)

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

Sure, if you can address the permission problem. In general, I do _not_
want cocoon to be able to modify its own configuration or class files as
that sounds like a security problem just waiting to happen. Personally,
I'd be happy with a new CVS repository just for modules. :)

- donald

View raw message