cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Duddleston" <>
Subject RE: Cocoon2 Design
Date Fri, 02 Jun 2000 23:37:16 GMT

> You simply make "Cocoon implement Block" and you're done.
> Piece of cake :)

I get the basic idea, but I don't have a full understanding of it. Just a
matter of getting in there a looking at all the code. BTW, I love the name
Avalon. I keep hearing the Brian Ferry song "Avalon" when ever I think about
it ;-)

> Craig knows all about it. He's just waiting for something to show up.

Like what?

> Also for Tomcat will just be a matter of doing "Tomcat implements
> Block", nothing more. They can start be "avalon-aware" (this means use
> other blocks directly) later on, if they think so.
> See, the power is create nice thing, not force others to use them.

Right, I get it.

> Thank you, deeply appreciated. :)

You deserve it.

> > services wrapper into Cocoon. Actualy there are lots of little
> things that
> > can be done at this point. Hopefuly people will continue to
> push and these
> > threads on intergrating JetSpeed/Turbine/Cocoon/Avalon... won't
> die out in a
> > day or so. BTW, I know Micheal Nash (Expresso framework) is all
> for sharing
> > code and has changed the license of Expresso to Apache, so his
> is another
> > possible player here.
> What's this? Never heard of it (sorry, nothing offensive, just
> ignorance)

What, Expresso? Used to be GPL, but switched the license so there is a
possibility to share code. A while back, we were planning on developing a
message forum for JetSpeed and Expresso, but ran into some issues regarding
persistence layer (Expresso uses DBObjects). Most of the code for the
message forum would be persistence related and it would not be real easy to
just port it over to JetSpeed. Still an issue today. Kevin is welcome to the
Expresso eForum code, but nobody wants to spend the time to make the
conversion. It would be a peice of cake if the same persistence layer was

> James uses an Avalon block to implement a persistent layer for Mail
> objects. This is just an interface and you can create your own block
> with any particular implementation of that interface (Castor, Ozone,
> InstantDB, serialization on disk, serialization on BLOB via JDBC,
> etc...). The only thing that james requires is that you implement the
>  org.apache.avalon.blocks.ObjectStore

Right, back to the framework vs. implementation issue. People want
implementations? But I can't blame them. I would like implementation myself.
But at least if the projects are sharing the same framework, interfaces and
so forth, then it is much easier to figure out the various projects.

> In fact, Avalon is more of a community rather than a real code factory.
> A sort of CPAN for interfaces, rather than real code. Then code, under
> the form of binary jars, can be downloaded _after_ you install your
> server.


> You plug james.jar in your avalon and it asks you:
> "There are 5 flavors of Object store present in the Avalon archive,
> which one do you want me to download for you?"
> (of course, if you want that feature, otherwise, it will download the
> standard components right away)
> Think about something like this for Cocoon:
>  The Cocoon component archive stores:
>     -5 generators
>     -13 filters
>     -8 serializers
>  which one you want to install?
> And your visual sitemap editing tool adds another box in your virtual
> drawer, along with metadata about author, functions provided, docs and
> all that.
> People this is not Sci-Fi, this is what I'm trying to do with the
> sitemap right now! And can be done at all levels: server, block and
> web-app.
> Can you imagine how easier it would be to install and create java
> software this way for new users?

All of the above is -Very Cool-. Thanks for spending the time to explain it.
Sorry for asking this question, I should look at the code, but how much of
this is implimented in Avalon currently? Man, so much to figure out...


View raw message