forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "yachting heritage" <cont...@yachting-heritage.com>
Subject Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source directory madness)
Date Mon, 16 Jun 2003 14:28:24 GMT
stop sending me message
----- Original Message ----- 
From: "Nicola Ken Barozzi" <nicolaken@apache.org>
To: <forrest-dev@xml.apache.org>
Sent: Monday, June 16, 2003 3:13 PM
Subject: Re: Forrest 0.5 outstanding issues (Re: Cleaning Forrest source
directory madness)


>
>
> 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