Design flaw in Source interface?

[ma...@tiger.com.pl]

I think that there is a deign flaw in Source interface, which precludes
implementation of important class of caching transformers.

I would like to start explanation of what is wrong with case of caching
CIncludeTransformer but everything below holds for whole class of "caching
including transformers".

Cocoon caching algorithm works like this: Cache holds cached pipeline alongside
its key and validity information. When new request comes, key and validity
information it generated for request pipeline. If cache holds pipeline for
request key, than validity information for all pipeline steps is evaluated, if
result of evaluation is positive than resource is acknowledged as valid.

How caching CIncludeTransformer works? 

When it comes to checking validity of CachingCIncludeTransformer step,
generation/transformation steps before CIncludeTransformer are valid (otherwise
cached pipeline would have had been discarded already), so list of sources to
include in new pipeline is the same as in old one. Then to validate include
transformation it is necessary to validate sources from that list. Sources
alongside validity information are contained in validity object of cached
pipeline...

General pattern that some information from previous pipeline steps is kept in
validity object, and used during evaluation of validity may be applied to other
including transformers. SQLTransformer variant being one of examples.

Sources of CachingCIncludeTransformer and IncludeCacheValidy are included in
cvs head.

Example usage:

x.xml:
<?xml version="1.0"?>
<x/>

y.xml:
<?xml version="1.0"?>
<z xmlns:cinclude="http://apache.org/cocoon/include/1.0">
  <cinclude:include src="cocoon://x.xml" />  
</z>

sitemap.xmap:
...
   <map:match pattern="x.xml">
     <map:generate src="x.xml"/>
     <map:serialize type="xml"/>       
   </map:match>

   <map:match pattern="z.xml">
     <map:generate src="y.xml"/>
     <map:transform type="cinclude"/>
     <map:serialize type="xml"/>       
   </map:match>

cocoon://z.xml:
<?xml version="1.0"?>
<z>
  <x/>  
</z>

So far everything works, x.xml is included into z.xml, if x.xml changes z.xml
reflects the change.

Where is the problem?

Problems starts when something like this is added to the sitemap:
   <map:match pattern="w.xml">
     <map:generate src="cocoon://z.xml"/>
     <map:serialize type="xml"/>       
   </map:match>

Changes in x.xml are still reflected in z.xml but not in w.xml. Why?

Pipeline w.xml uses FileGenerator which generates validity information from
inputSource.getLastModified():

    public CacheValidity generateValidity() {
        if (this.inputSource.getLastModified() != 0) {
            return new
            TimeStampCacheValidity(this.inputSource.getLastModified());
        }
        return null;
    }

In this case inputSource is an instance of SitemapSource which calculates
getLastModified as a hash of string representation of validity objects of
relevant pipeline. Than when validity of generation step of w.xml is evaluated
simply two hashes of validity objects are compared. It works if it is true that
isValid() method is equivalent to comparing hashes validity objects. It does not
hold for IncludeCacheValidity.

How to repair it? 

It is necessary to make accessible to FileGenerator validity
information about SitemapSource object?

What do you think? Are there any people interested in CachingCIncludeTransformer
and alike?

P.S.: I volunteer to make and test changes, as soon as solution is agreed.


Maciek Kaminski
maciejka@tiger.com.pl

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