forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Jose Pablos <>
Subject Re: Forrest: dynamic or static?
Date Mon, 22 Sep 2003 10:25:49 GMT
Jeff Turner wrote:
> I see we now have i18n'ed menus, where the language is chosen based on
> the locale of the requester.
> This feature is useless if you're rendering a static site with the CLI.
> The requester's locale will be that of the local machine.

That is not true!

> Then we have:
>  - The addition of XSP.  Lots of uses with dynamic Forrest, none (that I
>    know of) for a statically rendered site.

I gave you an example of XSP use for static rendered site. Plus this was 
requested by users!

>  - Lucene integration.  As it exists in CVS, it screws up statically
>    rendered sites, so is disabled.

Hold on here... The idea was to be disabled by default, This needs more 

> Being a Cocoon distribution, there is a huge amount of stuff that Forrest
> *could* include.  I think we need to draw a line, define what Forrest
> actually is, and stick to that.
> The line I propose is that Forrest should be regarded as an offline site
> generation tool that happens to have an online mode for rapid page
> development.  There should be no features _unusable_ from a static site.

The fact that there is a bug does not mean that we need to change our 

> For especially useful features, like searching, we can bend the rule and
> have online/offline equivalents (lucene and google).

-1 The fact that some features can be done only in live mode does not 
mean that we need to restict ourselves.

> I can demonstrate why I take such a hardline stance with a small
> benchmark:

Sure, but did you took in account how long took a whole web site to be 
render?, so If I made a modification, I need to wait more than 0.2 
seconds to see the results.

> Perhaps we're doing something stupid in our sitemap.  Perhaps Cocoon
> caching is crap.  Whatever the cause, we're stuck with the result.  I
> consider online Forrest to be too slow for anything other than
> development work.

I think that we have a problem with SVG. Whatever we do stupid on our 
sitemap will affect the render of offline generation. So we need to look 
into this issue as well.

> So I'd like to narrow Forrest's potential scope to *just* those features
> that can be expressed in HTML.  We get the best of Cocoon (sitemap
> expressivity) while leaving out the worst (performance, overhead).  This
> means Forrest will never evolve into some ultimate CMS, but there's
> enough of those in the world already.

-1  I would like to see both online or offline mode work, I have not 
seen any reason of why can not be achived, so I stick to that.

I like forrest to be focus on features needed by an small web site, but 
that does not mean to be some ultimate CMS.


View raw message