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: <41758BC7.6070709@apache.org>
Date: Tue, 19 Oct 2004 23:48:55 +0200
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] applying SoC on cocoon itself
References: <4173FB43.8020606@apache.org> <41743993.5080206@apache.org>
 <41744490.30202@apache.org> <4174B301.6030301@apache.org>
 <417566EF.8020800@apache.org>
In-Reply-To: <417566EF.8020800@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:
>
>> Stefano Mazzocchi wrote:
>>
>> <snip/>
>>
>>> and this solves *ALSO* the issue that was identified at the GT about 
>>> "virtual pipeline components" resolving services locally or remotely 
>>> (block-wise).
>>
>>
>> The current problem with VPCs is the context in which relative URIs 
>> must be resolved. We have not found a good solution for this as that 
>> depends on the point of view that is considered. What we're missing 
>> actually is the notion of "typed parameter" that would allow us to 
>> absolutize a URI at the closest point where we can determine that it 
>> is a URI and not a raw string.
>
>
> In the syntax I proposed, the uri="" becomes the identifier for the 
> service (thru relative to the block that exposes the service) and the 
> src="" becomes the identifier for the instructions for the service 
> (thus relative to the block that requires the service).


We already have this src="" attribute which currently is a raw string. 
Does this mean that we will enforce the contract on this by explicitely 
stating that it's a URI that will be resolved in the local context where 
the instruction is written?

We have to check if all of our current components use src as an URI.

> I think this solves the issue.


Mmhh... what if other parameters are also URIs?

<snip/>

>
> Right, nothing new, but a formalization of why the generator/@src is 
> so different from transformer/@src.


I have to read again your previous post as I don't see that difference. 
Moreover, we added some time ago the abilitity for a Serializer to also 
be a SitemapModelComponent, thus allowing it to have src="" and 
parameters. This is needed e.g. by the FOP serializer to read the 
configuration file.

In all cases (G, T, S), the src="" looks to me like the identifier of 
"something" that drives the function of the component. Some need it 
(FileGenerator, TraxTransformer), others don't (RequestGenerator, 
I18nTransformer).

<snip/>

> Now, since you are the TreeProcessor guru, how do we implement this? :-D


I had a discussion with Carsten at the GT about the relations of VPCs 
with the pipeline object and caching. The whole question is about we 
consider that VPCs and pipeline services must be an implementation of 
the corresponding Java interface (Generator, etc) or if it can be a 
"mini-Processor" that simply wraps a sitemap evaluation tree snippet.

If we want them to implement the Java interfaces, that requires to 
define "mini-pipelines" that chain the VPC's components and provide a 
combined cache key and validity to the enclosing pipeline object. That 
leads to loosing some of the features of the cache that caches up to the 
latest cacheable component in a chain (a VPC is considered as as a 
single component in this regard).

If we say that a VPC is a mini-processor, implementation is rather easy 
as it just means adding to the Processor interface some lookup method to 
get a Processor object that will be a wrapper around the VPC's 
instructions. Pipeline components added by the VPC are added as usual to 
a single pipeline chain, as we have today.

The problem of that second approach though, is that it's not possible 
for Java code to lookup e.g. a Serializer that would be defined by a 
VPC. Some components in Cocoon use that, e.g. the 
SourceWritingTransformer and the ZipArchiveSerializer.

I prefer the mini-pipeline approach which is simpler and more efficient 
than wrapping behind the interface, but we loose some of the current 
functionnality.

Or maybe a good solution can be to combine both approaches: the sitemap 
engine will use the mini-processor approach, and component lookups 
(which are not that often used) lead to the creation of a simple wrapper 
object implementing the Java interface, but that doesn't care about 
caching as SWT and ZipArchiveSerializer don't care about it.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }