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