Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 91872 invoked from network); 4 Jan 2000 06:48:30 -0000 Received: from phoenix.webslingerz.com (balld@206.66.49.24) by 63.211.145.10 with SMTP; 4 Jan 2000 06:48:30 -0000 Received: from localhost (balld@localhost) by phoenix.webslingerZ.com (8.8.7/8.8.7) with ESMTP id BAA00123 for ; Tue, 4 Jan 2000 01:45:47 -0500 Date: Tue, 4 Jan 2000 01:45:46 -0500 (EST) From: Donald Ball To: cocoon-dev@xml.apache.org Subject: Re: Parallelizing Cocoon Development In-Reply-To: <38711EEA.D2380B44@apache.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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