Re: [PROPOSAL] Pipeline hints (was Re: Auto/Manual_Cachingpoints pipelines & Cocoon-Views)

[Michael Melhem <mi...@fztig938.bank.dresdner.net>]

Hi Guys,

FYI, I have submitted a patch (Bugzilla [Bug 11386]) which completes 
auto caching-point 

(Bugzilla [Bug 11131] should also probably be applied along side this
patch..because it fixes a general bug in the pipeline imlementations)

So in SUMMARY (as dicussed/agreed in earlier threads) 
this patch implements auto caching-point as follows

------------
For pipelines that implement caching-point: 

if the ProcessingNode is of type  
     SimpleParentProcessingNode and the generator is already set
     and Node has one or more children, then return true; 
     this is a caching-point

or
     
if the ProcessingNode is of type 
      PipelineEventComponentProcessingNode
      and has one or more views set, then return true; this is a 
      caching-point

This "auto" behavior can be switched On/Off vi sitemap.xmap configuration
of the caching-point pipeline
<autoCachingPoint>On</autoCachingPoint>
------------

The manual(ie pipeline-hint="caching-point") behavior is 
meant to be always supported by caching-point pipelines.
(but its not yet fully implemented)

In the next week(s) I will try to to complete the "pipeline-hint"
manual caching as decribed in this thread.

Regards,
Michael Melhem

On Fri, Jul 26, 2002 at 12:40:34PM +0200, Michael Melhem wrote:
> On Fri, Jul 26, 2002 at 11:28:11AM +0200, Sylvain Wallez wrote:
> > Michael Melhem wrote:
> > 
> > >On Thu, Jul 25, 2002 at 09:44:56PM +0200, Sylvain Wallez wrote:
> > > 
> > >
> > >>Michael Melhem wrote:
> > >>   
> > >>
> > 
> > <snip/>
> > 
> > >>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).
> > >>   
> > >>
> > >
> > >Thats right, I didnt like the name "Leaf" for the reasons you mentioned
> > >above, but couldnt think of a better name at the time....hmmm
> > >
> > >PipelineStatementProcessingNode I like, but what do you of
> > >PipelineComponentProcessingNode? Wouldnt that be more accurate?
> > >
> > 
> > Yes, it looks better.
> 
> Ok good, PipelineComponentProcessingNode it is then!
> > 
> > <snip/>
> > 
> > >>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 ?
> > >>   
> > >>
> > >
> > >So you mean having the PipelineStatementProcesingNode 
> > >(or PipelineComponentProcessingNode) make available a pipeline-hint 
> > >to the implementing pipeline.
> > >
> > >I See...this sounds more generic, because the attribute is 
> > >not specific to one particular pipeline implementation. I like it.
> > >
> > >I imagine one could also set multiple pipeline-hints: 
> > > <map:transform src="foo.xsl" pipeline-hint="cachepoint,profilepoint"/>
> > > 
> > >
> > 
> > Exactly !
> > 
> > Note that this attribute can also be placed on component declarations. 
> > But because several pipelines implementations can be used in a single 
> > sitemap, an implementation should silently ignore hints it doesn't 
> > understand.
> 
> Yep sure.
> 
> > 
> > Proposed syntax for pipeline hints :
> > // A hints attribute has one or more comma separated hints
> > hints-attr :: hint [ ',' hint ]*
> > // A hint is a name and an optional value
> > // If there is no value, it is considered as a boolean "true"
> > hint :: litteral [ '=' litteral ]
> > litteral :: <a character string where ',' and '=' must be escaped with '\'>
> > 
> > This allows the following :
> > pipeline-hint="caching-point, connector=profiling"
> > 
> > Note also that sitemap variable expansion applies as usual :
> > pipeline-hint="caching-point={want-cache}" where "want-cache" is a 
> > sitemap variable (either a Boolean or a true/false string).
> 
> I cant argue with that.
> 
> > 
> > Talking about implementation now, what about translating this hint 
> > attribute to a Parameters object ? This would allow the parsing of hints 
> > to be centralized in both time and space :
> > - in time, because it would occur only once at sitemap load-time,
> > - in space, because it will be the responsibility of the sitemap engine, 
> > thus avoiding each pipeline implementation to code its own parsing.
> 
> I agree, we dont want each pipeline implementing its own parsing, its the job of
> the treeprosessor to interpret the sitemap. The pipeline implementation simply acts on
> the information it receives.
> 
> > 
> > This requires a change in the Pipeline interface, since we must add this 
> > Parameters object to each component addition method.
> 
> The Add and Set Methods on the Pipeline interface already take a
> "Parameters" object. So that should make that easy!
> 
> > 
> > Thoughts ?
> 
> Carsten is still on holiday, but it would be interesting to get his
> input on this.
> 
> I have a patch almost ready which will include the new 
> PipelineComponentProcessingNode (with the cocoon views stuff).
> >From there it shouldnt be too difficult to extended it to implement
> this PROSPOSAL.
> 
> Regards,
> Michael Melhem
> 
> > 
> > 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
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

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