Reinhard Poetz wrote:
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?
Your mail makes things a little bit more clear.
But (maybe I have missed some mails) how do you want to make this
Pipeline API?
E.g. a SAX-based pipeline is something different than image data running
through several filters. How do you want to prevent the use of a
SAX-events generating component together with an image data transformer?
What about something like it's used in clipboards: each component offers
a list of importable and exportable formats?
Just my 2 Räppli :-)
Florian
