forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory madness)
Date Mon, 16 Jun 2003 14:13:43 GMT


Jeff Turner wrote, On 16/06/2003 13.22:
> On Mon, Jun 16, 2003 at 12:02:31PM +0200, Nicola Ken Barozzi wrote:
...
>>I have the right hand side content stuff with the content pipeline 
>>pending too, and the eventual change in descriptors (although if we 
>>first decide as now to use less stuff in them it will be easier later 
>>on). Just to let you know I haven't forgotten it.
> 
> 
> Yep, neither have I.
> 
> Though I keep thinking, it's been around 3 months since we did a release,
> so we should probably defer all this fun descriptor stuff should be
> deferred till 0.6.

+1

> We should start a list of things needed for 0.5.. so far I've got:
> 
>  - Document alternative @tab scheme, decide what can be fixed for 0.5

+0

>  - Document how aggregate HTML/PDF works

+1 And add the possible link to the skinconf.xml

>  - Upgrade Cocoon to get rid of the MIME type bug (eg *.doc becomes
>    *.docnull).

Ok.

>  - Investigate the bug report that content/*.xml gets parsed when it
>    shouldn't

Ah, ok.

>  - Fix linkrewriter so it is configured once, instead of once per
>    transformer

Ugh, didn't know this,

>  - Speed!  Need to haul out the profiler and find out why normal Cocoon
>    CLI rendering is 5-10x faster than Forrest.

+1

I don't know if/when I'll have time, but I'll surely want to work on this.

We could also define a test site that gets generated every night and 
shows us if/how performance is affected. I can use my server here to do 
it since at night it doesn't do anything else, all I need is a test 
site. What about taking our site now, freezing it, and checking it in a 
test dir, so it remains as the base of the tests? Or IYHO is there a 
better real-life test site we could use?

Of course, this would not make it run faster, but spot if changes have 
increased-decreased real-life performance.

> Please add..

There was something else but I forgot (honest! ;-)
I think that the above are more than sufficient for now.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message