forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <d...@brondsema.net>
Subject Re: Forrest-core (Re: mini-forrest)
Date Mon, 06 Dec 2004 18:55:31 GMT
Quoting Ross Gardler <rgardler@apache.org>:

> Thorsten Scherler wrote:
> > El dom, 05-12-2004 a las 16:07, Ross Gardler escribió: 
> > 
> >>Sylvain Wallez wrote:
> >>
> >>>David Crossley wrote:
> >>>
> >>>>We could upgrade the cocoon xdocs to use these new DTDs because during

> >>>>Cocoon's 'build docs' it calls Forrest to do the work.
> >>>>
> >>>>However, when running Cocoon as as a webapp and using the live 
> >>>>documentation localhost:8888/docs/ you would notice that it uses old

> >>>>stylesheets that are dependent on the old DTDs. Stuck ...
> >>>
> >>>Ah damn, I missed that point :-(
> >>>
> >>>Mmmh... can't Cocoon embed a "mini-Forrest" for this local publishing 
> >>>(with the appropriate warnings that it's not the full Forrest) just like

> >>>it embeds a "mini-Jetty"?
> >>
> >>As more and more functionality gets moved into plugins proper this will 
> >>become a possability. If someone were to create such a "mini-forrest" we 
> >>could use this as a starting point for the fully plugin-ised Forrest. 
> >>Basically we could have a branch for this mimi-forrest and as we move 
> >>plugins out of core into plugins in that branch.
> > 
> > 
> > + 1
> > 

-1

I think the end result of a really small core and plugins for the capabilities 
is good, but this should be an iterative, gradual approach.  Lets continue to 
pull out input and output formats into plugins one at a time.

Even if someone has the desire and time to fork a "mini-forrest" (which I doubt 
they do), a non-gradual change will hurt the ability of other developers to 
follow along and help.

> > 
> >>We would start with the essential internals of Forrest in mini-forrest, 
> >>then gradually build it back up again until mini-forrest + plugins can 
> >>do everything trunk forrest can do.
> > 
> > 
> > That leads us back to the question I asked before in another thread:
> > 
> > What should has to go into the core?
> 
> I would propose that all we have in core is the plugin infrastructure 
> and the central part of our processing pipeline:
> 
> [input plugins] --> [internal format(s)] --> [output plugins]
> 
> The internal format(s) would be XHTML (may as well do this in the new 
> branch too), site.xml, tabs.xml (time to unify them as well?).
> 
> This would mean we need Cocoon and Ant in core of course.
> 
> The core should be capable of creating an unskinned XHTML site and 
> nothing more.
> 

Sounds like a good goal.  Instead of thinking about what should go into the 
core though, why don't we take what we have and see how much we can pull out of 
it?  Then when we get to the point where it isn't practical to move something 
from core to plugin, we're done.  Let's evolve (fast is fine), not rewrite.


-- 
Dave Brondsema : dave@brondsema.net 
http://www.brondsema.net : personal 
http://www.splike.com : programming 
http://csx.calvin.edu : student org 

Mime
View raw message