You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sergio Carvalho <sc...@criticalsoftware.com> on 2000/01/25 13:19:03 UTC

[C2] [Summary] Proposal for caching

Hi all,

Here's the summary from the ongoing discussion about C2 caching, that ran under the subject lines of 'caching system idea', 'idle thoughts in caching in c2' and 'Proposal for caching'. 

The discussion floated around two main points:
 1) Should cache be explicit on the sitemap? 

I think we all came to agree that an implicit cache is better, but that there are cases where caching strategy and method can't be decided automatically. The middle ground is obvious: a default automatic cache should be in place, but two things should be overridable: 

    a) The CacheValidator class, which is responsible for determining if the processing step is 'dirty'.

    b) The CacheStore class, responsible for storing the generated content. 

Declaration of these overriden classes should be on the sitemap.

 2) Should intermediate steps be cached?

This boils down to answering the question: Can generators get input from sources other than those declared in the stemap?

I believe the answer is 'yes', generators do get input from sources other than those declared in the sitemap, so intermediate steps must be cached. 

Nevertheless, some transformers act only on their declared input, and caching their input is useless (one can cache their output instead). One can only find if this is the case by asking the transformer itself, so a method for this should be on the Cacheable interface (or we could distiguish between transformers and translators).

Based on these points, here's a proposal, based on Carsten's:

1. Each cacheable transformer implements a 'Cacheable' interface, which contains the method:
    boolean isDynamic(); // True if transformer acts on inputs not declared on the sitemap
   Dynamic transformers must provide a 
    CacheValidator getCacheValidator();
   method that returns a CacheValidator, responsible for determining if the generator is 'dirty'.

2. Generators are treated like dynamic transformers, with no sitemap-declared input. 

3. Based on the cacheable interface, cache is stored on the input of every non-cacheable or dynamic transformer.

4. Cache retrieval is done by asking each dynamic component in the pipeline whether it is 'dirty'. If it is dirty, its inputs are retrieved from the cache store, and normal processing begins.

Thanks Donald, Paul, Giacomo, Stuart and Carsten, for participating (sorry if I missed someone). Thanks specially to Carsten who wrote the proposal document that is the basis for this summary.

--
Sergio Carvalho
---------------
scarvalho@criticalsoftware.com


XSP compilation and classpaths problems

Posted by Marc van Kempen <ma...@bowtie.nl>.
Hi All,

I have run into a very annoying problem and I hope you can help
me.

I'm trying to setup Apache jserv 1.2 and Cocoon, to run into 
different virtual servers.

However, I have an application that I want to install into several 
virtual servers. The application version might differ, but the
names will be the same, so I want
to completely separate them. I thought I could do that by putting
the 'jars that make up the application into the zone repository path.

I included cocoon.jar in the repository as well. It works reasonably
well, however when I to run an xsp file, I get compilation
errors, reporting that the compiler can't find the classes that I put
into the repository instead of the classpath.

On further reflection and inspection of the source code, this is 
logical since only the classpath entries are given to the compiler,
the compiler never sees the repository entries. I'm speculating
that it would work when the class would be generated, on the other
hand a separate classloader is instantiated for the xsp generated
class, so it might not see them at all. (if I read correctly)

But then how am I supposed to get the result I'm looking for, or
is this not possible with the current design? Is this a crazy
thing that I want?

I thought about changing the code for the xsp compiler, but I can't
think of a portable way to do it. At best it would be very jserv
specific.

So, please any suggestions?

Regards,
Marc.