Re: Parallelizing Cocoon Development

[Donald Ball <ba...@webslingerZ.com>]

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

Re: Parallelizing Cocoon Development

[Donald Ball <ba...@webslingerZ.com>]

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

Re: Parallelizing Cocoon Development

[Stefano Mazzocchi <st...@apache.org>]

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 cocoon.properties 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?

Right.

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.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------