cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Pruy <Rainer.P...@Acrys.COM>
Subject Re: Layered software designs
Date Thu, 27 Mar 2008 21:59:11 GMT


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

Mime
View raw message