Return-Path: 
 <cocoon-dev-return-29786-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 80014 invoked by uid 500); 25 Jul 2002 19:44:50 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 79991 invoked from network); 25 Jul 2002 19:44:49 -0000
Message-ID: <3D405538.4000302@anyware-tech.com>
Date: Thu, 25 Jul 2002 21:44:56 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Auto/Manual_Cachingpoints pipelines & Cocoon-Views
References: 
 <Pine.LNX.4.43.0207251604070.30946-100000@fztig938.bank.dresdner.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Michael Melhem wrote:

>Dear Cocoon Gods,
>(Flattery will get you everywhere!)
>

We're not god, but only grown-up contributors ;)

>In Particular:
>Attn: Sylvain Wallez
>Attn: Carsten Ziegeler
>
>FYI, I have been working to complete "cachingpoint" (CP) pipelines so
>that auto CP (ACP) is fully functional (and capable of supporting
>manual cachingpoint).
>
>Changes include:
>1. Cachingpoint pipeplines implement configurable. So
>its now possible to switch between cachingpoint policies easly.
>
><map:pipeline name="cachingpoint" src="...impl.CachingPointProcessingPipeline">
>  <cachingpoint-policy>...AutoCachingPointStrategy</cachingpoint-policy>
>  <!-- cachingpoint-policy>...ManualCachingPointStrategy</cachingpoint-policy -->
></map:pipeline>
>
>2. Introduced a new TreeProcessor Node called
>SimpleLeafProcessingNode.java (as opposed to SimpleParentProcessingNode).
>
>SimpleLeafProcessingNode groups the common cocoon-views behavior at higher
>level and makes it easier support manaul cachepoints etc.
>
>Thoughts, comments ? :-P
>

Shouldn't it be better "PipelineStatementProcessingNode" ? The concerned 
nodes are those that add a component to the pipeline, and not all leaf 
nodes (map:redirect and map:call are leafs).

>THOUGHTS ON MANUAL CACHINGPOINTs (MCPs).
>
>Does it make sense to have a MCP on anything other than "Leaf" Nodes?
>

...other than "pipeline statement" Nodes ? :)

>That is, Nodes which dont subclass SimpleParentProcessingNode?
>

Be careful here : you're mixing implementation helper classes (that 
aren't related to the sitemap at all) with your specification of the the 
sitemap statements that can define a cache point. Let's not bias the 
spec by "implementation details", as Stefano likes to call them !

>As with cocoon-views, I would say the answer is *no*..
>ParentProcessingNodes are not candidates for MCP's)
>
>The current cachingpoint behavior flags a cachingpoint whenever a
>"leaf" node is indicated to have one or more "views". So in effect,
>we already have a mechansim for manual cachingpoint (well close,
>you still need to have a view defined).
>
>I was thinking that one possibility is to extend this "views" behavior
>so you can have something like the following:
>
>  <map:transform src="../simple-samples2html.xsl" label="cachingpoint"/>
>
>Where in effect, you manually label a pipeline component as being a
>cachingpoint.  In this case, "cachingpoint" is not a view but a
>"resevered" word to indicate that this component is a manual cachingpoint.
>
>After this fashion, you can also label components as manual "cachingpoints"
>within the <components> section of the sitemap.xmap (as with cocoon-views)
>  
>

Although this reserved view name seems elegant at first, it finally 
seems to me like a hack, as we use a totally different concept (the 
views) to configure the pipeline caching behaviour.

>(alternatively you can seperate the concerns by having something like
>  <map:transform src="../simple-samples2html.xsl" cachingpoint="true"/>)
>  
>

This seems more clear, but introduces attributes on sitemap components 
related to a particular implementation of the pipeline, so I don't like 
it so much either : what if several pipeline implementations require 
some special attributes ?

>Any thoughts on this?
>  
>

What we want here is in fact to be able to give the pipeline (whatever 
its implementation) a hint on how it should handle a particular pipeline 
element. So we can simply allow a hint attribute to be specified on 
pipeline statements :

  <map:transform src="foo.xsl" pipeline-hint="cachepoint"/>

This allows any pipeline implementation do define it's own hints (e.g. 
profiling or logging a particular pipeline component).

What do people think ?

Sylvain

-- 
Sylvain Wallez
 Anyware Technologies                  Apache Cocoon
 http://www.anyware-tech.com           mailto:sylvain@apache.org




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