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
Reinhard Poetz schrieb:
Dev at weitling wrote:
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
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
Rainer Pruy wrote:
Hi, I was off the net for some time and while catching up this discussion I
also got the feeling of being somehow lost a bit in the different aspects of
the discussions
From what I see the starting point was
the (technical) question of how to get rid of a unwanted
Rainer Pruy wrote:
Reinhard Poetz schrieb:
Dev at weitling wrote:
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
Joerg Heinicke schrieb:
On 26.03.2008 09:14, Reinhard Poetz wrote:
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
Reinhard Poetz wrote:
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
Is sourceresolve where the Apache XML Commons Resolver
is
Steven Dolg wrote:
Joerg Heinicke schrieb:
On 26.03.2008 09:14, Reinhard Poetz wrote:
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
David Crossley wrote:
Reinhard Poetz wrote:
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
Is sourceresolve where the Apache XML Commons
Reinhard Poetz wrote:
David Crossley wrote:
Reinhard Poetz wrote:
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
Is sourceresolve
David Crossley wrote:
Reinhard Poetz wrote:
David Crossley wrote:
Reinhard Poetz wrote:
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
Is
Yes, using Cocoon pipelines in Ant is one of my long-time favorits ;-)
Reinhard
Bruce Atherton wrote:
I'm with you, too.
Just as an example, I think it might be useful to use Corona as the
basis for a new Ant task called Pipeline. That task could do any number
text transformations to a set
On 27.03.2008 02:25, Steven Dolg wrote:
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
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
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
Dev at weitling wrote:
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
Reinhard Poetz wrote:
Dev at weitling wrote:
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
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:
Ralph Goers schrieb:
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
On Mar 26, 2008, at 9:14 AM, Reinhard Poetz wrote:
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
Do you really need both URL and
Vadim Gritsenko wrote:
On Mar 26, 2008, at 9:14 AM, Reinhard Poetz wrote:
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
Do you really
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
On Mar 26, 2008, at 14:44, Ralph Goers wrote:
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
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
Steven Dolg wrote:
Ralph Goers schrieb:
Appealing? yes. Actually implementable in Java so that it isn;t even
more complicated than what we have? I don't know.
Just curious - do you have doubts, that this is achievable
specifically with Java, or generally with any language?
Taking 5
I'm with you, too.
Just as an example, I think it might be useful to use Corona as the
basis for a new Ant task called Pipeline. That task could do any number
text transformations to a set of files as part of a build process. Here,
caching is a non-issue for the most part since the point of
On 26.03.2008 09:14, Reinhard Poetz wrote:
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
27 matches
Mail list logo
