[c2] FileMonitoring & Re: cvs commit: xml-cocoon/webapp/docs/samples/svg henryV.svg opac.svg

[Berin Loritsch <bl...@apache.org>]

dims@apache.org wrote:

> dims        01/01/08 06:31:09
> 
>   Modified:    lib      Tag: xml-cocoon2 batik-all.jar
>                src/org/apache/cocoon/components/parser Tag: xml-cocoon2
>                         XercesParser.java
>                webapp   Tag: xml-cocoon2 sitemap.xmap
>   Added:       webapp/docs/samples/svg Tag: xml-cocoon2 henryV.svg opac.svg
>   Removed:     webapp/docs/samples Tag: xml-cocoon2 opac.svg
>   Log:
>   Added a more complex sample for SVG (borrowed from Batik).

This is pretty cool, except for the time it takes to generate.
The first access on an Athlon 750 w/256 MB RAM, it takes ~26
seconds--the second access took ~16 seconds.  Any longer, and
the request would time out on many browsers.

I noticed that the SVG Serializer doesn't check to see if the
file has modified since the last access.  So what happens is
that the file is read and processed, but if the rendered image
is the same, then we send the already rendered image--or something
to that affect.

On something that is not a dynamic generator, (i.e. not a serverpages
generator, and does not have a dynamic transformer (i.e. not a
SQLTransformer), then we should use a cached version.

So this brings a number of concerns to the table:

1) We need to identify if the different points of the chain are
    dynamic or static (Generator, Transformer, Serializer).
2) We need to cache the results for each static path.
3) We need to update the results only if a file in the chain
    have been changed.
4) We need to immediately serialize the cached result if none
    of the items in the chain have changed.