Caching

[Keiron Liddle <ke...@aftexsw.com>]

I will start with some comments on caching since I have looked at this.

There is another type of caching needed. Caching objects in memory to
disk (or other medium) to avoid excess memory growth. The obvious case
is when there are lots of forward references on every page. The page can
be saved using serialization and once all references are resolved it can
be read back and the resolved things fixed then rendered. The other case
is when an output format needs to hold back a lot of data until it has a
length or reference etc. before it can write the data to the output
stream.
This is just temporarily saving streams of data until it can be used.
The only real problem is to determine when it should be used (number of
objects, memory use etc.).
How or if it should be used will depend on the situation. This is where
the container could supply an implementation.

The other type of caching which you are talking about is only relevant
for images as far as I know.
In my opinion we have very different caching requirements than say
cocoon. Most of the important parts are around the cache, synchronize on
finding and loading, the context and remembering invalid images.

The cache could hold onto images more strongly until the renderer uses
it. Once the renderer uses the image it may never need the cache again
for that document and image. Once the document is finished it can
release the image to the context.

The document could contain many references to an image but the renderer
will only need to read it once or the opposite the document could
contain the image once but the renderer needs to read it many times.

The context depends on the url resolving context and possibly the
document.

So the questions are how do we setup the context, does it cache before
or after the renderer is done with the image and what cache should be
used?

So a possible solution could be to use the component manager that would
be available on the user agent (or somewhere similar). This also
contains the url resolver giving the same context.
The default implementation would be obtained from the component manager.
There is a size based cache before the renderer is done with the image.
Afterwards it uses a LRU cache (or if the context is a document - no
cache).

The current code will need to be adjusted for the component manager
context and use the ContextImageCache with different caching mechanisms.

Well, that's may take.

Keiron.

On Fri, 2002-05-31 at 23:34, J.Pietschmann wrote:
>   = Caching =
> Caching is an interesting topic. It comes in two flavours:
> 1. Caching of stuff like images within a rendering run.
> 2. Caching across multiple rendering runs on reused objects
> The first is not only concerned with efficiency but also with
> predictability. Consider
>   <fo:page-sequence initial-page-number="1">
>      <fo:static-content>
>        <fo:external-graphic src="http://dynamic.com/curr-time.gif"/>
>     ...
>   <fo:page-sequence initial-page-number="20">
>      <fo:static-content>
>        <fo:external-graphic src="http://dynamic.com/curr-time.gif"/>
> Will the two page sequences feature the same or different
> pictures in the page header?
> XSLT explicitely says that within a transformer run, multiple
> access to the same URL results in the same content.
> The other interesting question is whether object reuse implies
> caching stuff like images across rendering runs. Whether this is
> useful depends on how often and how much stuff is shared. The
> use cases vary from rendering the same document several times
> to rendering documents sharing the same logo in the header to
> rendering documents at random.
> 
> Choice 1:
> No caching at all, or a non-guaranteed caching. Risk reading
> sources multiple times, including possibly dynamically changing
> content.
> Perhaps we should leave the cache problem to another application
> layer. Cocoon appears to be quite good at it, no reinvention of the
> wheel necessary.
> 
> Choice 2:
> Guarantee an URL is only read once within a rendering run. May imply
> memory problems.
> 
> Choice 3:
> Expose caching across multiple renderings on a reused object.
> Needs an API for Cache control.
> (My opinion: not recommended).



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org