forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Forrest-core (Re: mini-forrest (was Re: Recommended DTD version?))
Date Mon, 06 Dec 2004 12:41:40 GMT
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
>>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.

> In the light of cocoon writing a new core, maybe we should think about
> integrating cocoon smoother into forrest. Over in lenya there is a
> recent thread about cocoon versions. That made me think about how can we
> keep everything as small as possible. I mean something like including
> cocoon via svn:external.

I'm not sure of the implications of this. Does svn:external mean that 
when checking out Forrest we also checkout relevant parts of the Cocoon 
tree and when doing / in Forrest this builds Cocoon.

If so, what are the implications on bandwidth usage, will this use less 
than the existing download the jars approach?

What advantages do we gain from this.

>>I'd be +1 with assisting with this work, although my baby is due any day 
>>so expect me to slow down soon.
> All the best to your wife, the baby and yourself from the forrest
> community!!!

Thanks, as you can tell, I'm very excited!!!


View raw message