Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <425A819F.3000407@apache.org>
Date: Mon, 11 Apr 2005 15:54:39 +0200
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [Ann/RFC] Virtual Sitemap Components
References: <42599554.2080809@nada.kth.se> <425A7079.2000802@apache.org>
 <425A756E.7060709@reverycodes.com>
In-Reply-To: <425A756E.7060709@reverycodes.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Vadim Gritsenko wrote:

> Sylvain Wallez wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>>     <map:transformers default="xslt">
>>>       <map:transformer name="virtual2" 
>>> src="org.apache.cocoon.transformation.VirtualPipelineTransformer">
>>>         <map:source param="src2"/>
>>>         <map:transform src="vpc-include.xsl">
>>>            <map:parameter name="file" value="{src}"/>
>>>         </map:transform>
>>>         <map:transform src="vpc-include.xsl">
>>>            <map:parameter name="file" value="{src2}"/>
>>>         </map:transform>
>>>       </map:transformer>
>>>     </map:transformers>
>>>   </map:components>
>>
>>
>>
>> It seems weird to me to see sitemap statements in the 
>> <map:components> section. But they're also used as any other 
>> component. Hmm...
>>
>> What about either:
>> - leave them in <map:components> but with special element names, e.g. 
>> <map:virtual-generator> that maps to the VirtualPipelineGenerator class
>
>
> It can be
>   <map:components>
>     <map:generators>
>       <map:virtual name="a">
>
> That's enough information to build it.
>
>
>> - or separate them in a <map:virtual-components> section just as we 
>> have today <map:resources> and <map:views>?
>
>
> What would happen with default component? If we go this route,
>
>     ...
>    </map:components>
>
>    <map:virtual>
>      <map:transformers default="???">
>        <map:transformer name="a">
>          ...
>        </map:transformer>
>      </map:transformers>
>    </map:virtual>
>
> What will be in place of "???", and how this would relate to the 
> default transformer in the map:components section?


Good point. So let's go for <map:virtual-blah> in <map:components>.

>> I would favor the second solution, even if this doesn't seem to be 
>> absolutely necessary for the implementation.
>
>
> I'd prefer first solution, which lacks the problem of default components.
>
> <snip/>
>
>>> VPCs are not cacheable yet. Its probably not that hard to add 
>>> caching, but it requires that we extend the ProcessingPipeline 
>>> interface with some methods that are needed for VPCs. It also 
>>> requires that we find some syntax for declaring what pipeline type 
>>> that should be used for a specific VPC.
>>
>
> Not sure that this is desired. We should have configurable caching, 
> with following levels of caching:
>
>   * No Caching: Returns null key
>   * Caching: Returns pipeline key, validity
>   * Caching, with private cache: Same as above, plus caches output of 
> the pipeline locally (same as caching pipeline).


I'm wondering if we need this level of choice. If the surrounding 
pipeline isn't caching, key and validity will never be computed. Also, 
if we want to specifically cache the output, we can use the 
caching-point pipeline in the caller's pipeline.

So in the end, looks like we just need a caching pipeline.

>> Why do we have to choose a particular pipeline type? Isn't this 
>> defined by the <map:pipeline type=""> surrounding the call to the VPC?
>
>
> No, that pipeline is not used within VPC. VPC as a component is part 
> of this external pipeline, but internally it has its own.


Ok.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director