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 [EMAIL PROTECTED]
_________________________________________________________________________
