Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of Rainer.Pruy@acrys.com
 designates 212.222.64.34 as permitted sender)
Message-ID: <47EC18AF.6070806@acrys.com>
Date: Thu, 27 Mar 2008 22:59:11 +0100
From: Rainer Pruy <Rainer.Pruy@Acrys.COM>
Organization: Acrys Consult GmbH & Co. KG
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Layered software designs
References: <47E509B2.7050003@tuffmail.com> <47E50A75.8090001@apache.org>
 <47E51B61.2050701@tuffmail.com> <47E7F20D.3020308@tuffmail.com>
 <47E8A7CE.6040508@apache.org> <47E9061C.5030105@tuffmail.com>
 <47E911D9.9040503@apache.org> <47E9B1CA.6050202@gmx.de>
 <47E9FC91.3080004@apache.org> <47EA1B66.5040907@apache.org>
 <47EA4C3D.9070802@apache.org>
In-Reply-To: <47EA4C3D.9070802@apache.org>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit


Reinhard Poetz schrieb:
> Carsten Ziegeler wrote:
>> The question is now if we need support for caching in the low level
>> apis or if it is possible to have a layered approach - which would
>> make the entry barrier much easier.
> 
> Yes, this layered approach is what I'm aiming for. All the reactions in
> this thread make me think that everybody, who has commented on this
> mailing list so far (except Carsten), believes that we want to throw
> away good things that have profed to be useful in many situations.
> Rest assured, that's not the case. Carsten and I only want to break up
> this all-or-nothing situation that we (still) have now.
> 
> What I want to see is a concise pipeline API that comes with only little
> overhead in terms of its learning curve and its dependencies on
> third-party software. Usually this means that we stick with standard
> APIs as much as possible - and I think this rule applies for our
> situation too.
> 
> This means that the user of the API only needs to learn as little as
> possible. When he wants more, we offer additional modules that help him.
> Since he has a concrete need, the motiviation to learn something new is
> much higher than when he has to learn everything right from the beginning.
> 
> If you want to learn how this whole concept *might* apply for a next
> generation Cocoon, have a look at Steven's and my "Exploring Corona"
> mail from last week
> (http://marc.info/?l=xml-cocoon-dev&m=120611990603725&w=2).
> 
> 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.

I did see:

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

Sitemap API: responsible for executing pipelines

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

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

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


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

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.

Rainer