Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <47EC06EE.5040802@apache.org>
Date: Thu, 27 Mar 2008 21:43:26 +0100
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Exploring Corona
References: <47E3EDB1.9040009@apache.org> <47EBE3FB.5020502@apache.org>
In-Reply-To: <47EBE3FB.5020502@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Carsten Ziegeler wrote:
> Intersting stuff - thanks Reinhard and Steven for starting this and 
> sharing it with us.
>
> Finally I had time to have a *brief* look at it and I have some 
> remarks :)
>
> I think the pipeline api and sitemap api should be separate things. So 
> the invocation should rather be in the pipeline api as the base of 
> executing pipelines. We could than split this into two modules.
>
> I'm not sure if actions belong to the pipeline api; i think they are 
> rather sitemap specific. All they do wrt to the pipeline is to change 
> the invocation perhaps. So this could also be done before starting the 
> pipeline and get the action stuff out of the pipeline api.

Yes, actions definitely don't belong to the pipeline API. They are 
sitemap control structures, just like matchers and selectors. The main 
difference between matcher and action (besides the pattern/src 
attribute) is that actions are allowed to have side effects while 
matchers should not.

> The classes should be put into different packages: we should separate 
> between the pure api, helper classes and implementations. This makes 
> it easier to use the stuff in an osgi environment.
>
> Ok, final comment for today, the idea of abstracting the consumer and 
> the producer seems appealing. It's like the javax.xml stuff (Result, 
> Source); the javax.xml stuff has the advantage that the implementation 
> knows which results and sources are possible: there are only a 
> handfull of subsclasses; adding own results or sources simply is not 
> supported.
> I fear we will have to follow the same path (which might not be bad).

Reminds me of some old thoughts I had about a Cocoon 3. This can be the 
role of a collection of adapters that would convert data for components 
that can't directly talk to each other. This complexifies the picture a 
bit, but would allow for advanced things such as non-XML pipelines, 
mixing SAX, DOM and StAX transparently to e.g. perform some 
content-aware construction of the pipeline, etc.

Sylvain

-- 
Sylvain Wallez - http://bluxte.net