Grzegorz Kossakowski wrote:
Ralph Goers pisze:
Reinhard Poetz wrote:
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?
Appealing? yes. Actually implementable in Java so that it isn;t even more
complicated than what we have? I don't know.
+1.
I've got my hands dirty with URL stuff from Java and I fail to see how we can
avoid using Source interface, especially when caching comes in.
The issue is not about lack of the will but more about lack of ability, at
least at this stage. Examine current
Source/SourcaFactory/CocoonSourceResolver usage patterns to see what I mean.
Why do you want to give up even before you start? Because things _seem_ to be
difficult?
At the current stage we haven't even defined what we expect from caching. Please
let's first put all our requirements on the table.
My (and that of many others) *main requirement is a layered software design*
that makes Cocoon easily useable and embeddable in many different environments.
Given, caching is important, but compared to that it is of subordinate relevance.
Maybe we have to go back to the old Source/SourceResolver solution because
everything is impossible as some of us think, but let's decide this latter when
we are sure that there is no better alternative.
--
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]
_________________________________________________________________________
