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
