forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gav...." <brightoncomput...@brightontown.com.au>
Subject RE: [RT] A new Forrest implementation?
Date Thu, 17 Aug 2006 13:28:12 GMT


> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: Thursday, 17 August 2006 6:58 PM
> To: dev@forrest.apache.org
> Subject: Re: [RT] A new Forrest implementation?
> 
> David Crossley wrote:
> > Ross Gardler wrote:
> >> This is a Random Thought. The ideas contained within are not fully
> >> developed and are bound to have lots of holes. The idea is to promote
> >> healthy discussion, so please, everyone, dive in and discuss.
> >
> > I don't know where to begin to answer this. One way
> > is with more random thoughts. In such RT threads we
> > have the freedom to throw wacky ideas into the mix.
> >
> > Intertwine that with our own use-cases, etc. and as long
> > as we all help to calmly discuss, then a strong combined
> > solution should emerge.
> >
> > I do agree that we could build a better framework.
> >
> > Perhaps we currently try to use Cocoon for too much.
> > Perhaps Cocoon should not be the controller, i.e. Forrest
> > should control the whole process and decide which input
> > plugins and which output plugin to use. Perhaps Forrest
> > should provide some ways to generate the internal format
> > from the various sources. Perhaps Cocoon could be an
> > optional way to handle those stages, e.g. if i prefer
> > Cocoon then it should be simple for me to add it and use
> > its sitemap and generators and transformers to do the
> > input processing in my input plugins.
> >
> I can't tell whether it would be better to use Cocoon within Forrest or
> not as I don't know that much of current Forrest.
> 
> But as some of you might be aware, Cocoon is trying to change with the
> newer versions in many aspects. We moved away from Avalon to spring (you
> can now use simple pojos as components) and we are trying to come up
> with smaller reusable parts of the core, like just a pipelining api, a
> sitemap processor and so on (which would be separate jars)
> In addition, we have come up with new ways to invoke Cocoon, so you
> could for example write a controller servlet for Forrest which then
> internally invokes Cocoon (and a pipeline within Cocoon). We are also
> discussing to simplify interfaces and the like. So in the end I guess we
> are at least aware of some of the problems Forrest is facing. We only
> lack some resources...
> 
> So, one possibility for you could be to discuss some things within
> Cocoon and perhaps we can fix these issues together. But again, I don't
> know what might be best for you.
> 
> Carsten

Thanks for popping in and giving this update. This post along with David's
Sees me swinging towards taking a better look at Cocoon, what more it has
To offer that we have not yet utilised, and improving on what we already
Have.

I was of the mind before that I didn't much care whether Cocoon stays or
Goes, but I'm thinking now we should at least take another good look at it.

Gav...

> 
> --
> Carsten Ziegeler - Open Source Group, S&N AG
> http://www.s-und-n.de
> http://www.osoco.org/weblogs/rael/
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.11.0/420 - Release Date: 8/16/2006



Mime
View raw message