cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Layered software designs
Date Fri, 28 Mar 2008 09:56:30 GMT
Rainer Pruy wrote:
> Reinhard Poetz schrieb:
>> The idea of Corona is having a concise core that doesn't have any 
>> dependencies on a particular component container (Spring, OSGi, etc.), 
>> source resolving mechanisms or environment (http, java  only, etc.) or even
>> the type of the components (XML-SAX event stream, XML-Stax event stream,
>> binary streams, etc.) that are linked together in a pipeline.
>> 
>> A simple scenario could be:
>> 
>> Pipeline API  +  java.net.URL   +  XML-SAX components
>> 
>> 
>> A more advanced scenario could consist of
>> 
>> Pipeline API  +  Sourceresolve  +  XML-SAX components  +  Sitemap Engine
>> 
>> 
>> or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here
>> you are:
>> 
>> Pipeline API  +  Sourceresolve  +  HTTP-enabled  +  Sitemap Engine  + 
>> Spring XML-SAX componnents
>> 
>> 
>> This layered approach makes Cocoon easily embeddable in any Java 
>> application and Cocoon's learning curve becomes more gradual.
>> 
>> Is such a situation only appealing to Carsten, Steven and me?
>> 
> 
> It's appealing to me also.
> 
> However, I'm not sure I did get the "layers" correctly.

Note: All my answers are related to Corona. Here we go:

> I did see:
> 
> Pipeline API: responsible for composing different components, introduces the
> notion of Producer/Consumer and first and last component

the pipeline api will be enough to execute pipelines too.

> Sitemap API: responsible for executing pipelines

no, the sitemap is a builder that builds pipelines and is put on top of the 
pipeline API.

> Spring:  responsible for setting up layers and identifying implementations to
> "wildcard" functionality (not really a layer for itself?)

Corona has a SpringComponentProvider which is used by the sitemap to lookup its 
components. Spring manages the components but is completly hidden behind the 
ComponentProvider interface. This makes it very easy to use alternative 
containers (e.g. OSGi).

> URI API (had no better term at hand):  responsible for interpreting protocol
> strings for resource access. Currently two implementations in dicussion: URL
> and SourceResolver

yes. And as Sylvain and you pointed out, we maybe don't even need the 
Sourceresolver anymore.

> Pipeline Components? really a layer or just implementations of Pipeline API

Steven came up with the idea of having components that belong to different 
layers. The first type is useable in every environment. This could be a 
SAX-based FileGenerator or a SAX-based XSLTTransformer. There is no need for any 
ties to the ServletAPI. Then there might be a second group of components that 
are based on e.g. the Stax-API.

A third group of components has relations to the ServletAPI in order to produce 
useful results.

In short, the idea is that the pipeline API is completly independant from any 
environments. It can "only" connect components that belong together.

> Can we line out the intended or existing "layers"? I do feel this would help
> focussing the discussion.

I hope that my explanations above are already helpful. Steven and I will work on 
Corona next week again and we hope that we can show how this "layered design" 
can be applied in code.

> We then can have a track reflecting actual layers, a track exploring
> interaction among layers (e.g caching, configuration...), and a track
> pondering implementation aspects.

-- 
Reinhard Pötz                            Managing Director, {Indoqa} GmbH
                           http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair        reinhard@apache.org
_________________________________________________________________________

Mime
View raw message