cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Tripodi" <>
Subject Re: Our idea for simple StAX workflows
Date Wed, 10 Dec 2008 11:57:15 GMT
Gute Morgen Andreas ;)

very nice thoughts, congratulations :)
I like your "backtracking" thoughts about StAX Pipeline component, I'm
just curious reading the implementation and seeing how a SAX&StAX
Pipeline works.
Best regards... alles gute!

2008/12/10 Andreas Pieber <>:
> Hi,
> Since Reinhard introduced us to the community we have worked quite hard on our
> first prototype for a StAX based cocoon pipeline and are now ready to present
> our thoughts about how StAX could be used in cocoon.
> Of course there are many possible ways to do such an implementation. Some of
> them as multithreading, continuation and others were already named by Sylvain
> and Thorsten.
> Before presenting our ideas, or discussing already mentioned ideas we want to
> state the intention and the goals of this project as we think about.
> First of all we do not want to replace SAX. In our opinion StAX should only
> allow a developer to solve problems requiring a quite complex state handling in
> SAX in an easy and (more or less ;) ) intuitive way to work it. Further more we
> also want new cocoon developers to be able to use/write cocoon StAX-Pipelines
> within a few hours, by keeping it as simple as possible and providing examples
> to make it very easy to adopt them to their own problems.
> We are Sylvains opinion that it is possible to build StAX pipelines by using
> continuation. But this approach would add several disadvantages as handling the
> "break points", additional dependencies, increasing the complexity for developer
> and maybe continuation adds more problems than it solves. Since we have another
> approach how to do it in a more simple way we think we shall avoid continuation.
> Most of the disadvantages of continuation are also valid for multithreding.
> Additional it could happen that developers, using many components, could reach
> the thread pool limit.
> We started with this project by evaluating different StAX implementation. Namely
> Woodstox[1], Axiom[2], and the JSR reference implementation included by the jaxp
> packages in the JDK6.
> Finally we come to the following conclusion:
> Woodstox: More or less the reference implementation, but adds an additional
> dependency.
> Axiom: As already mentioned by some people in the mailing list axiom is a nice
> idea, but would add too much complexity at this stage of the project.
> JSR reference implementation: Comes for "free" and with an acceptable speed.
> Thats the one we decided for.
> First of all our implementation does not change any of the existing cocoon
> interfaces. Neither do it changes the appearance to the user (especially the
> usage) .
> Due to the nature of pull parsing, internally we are proposing an inversion of
> control as following:
> Starting the pipeline the Starter propagates the initialization of the pipeline
> through the components to the finisher. From therefore the finisher pulls the
> elements from its parent and writes them directly to the output. This pull is
> than propergated back through all components.
> Cause of the nature of the XMLEventIteratorApi every pull produces a resulting
> XMLEvent object representing the actual node. Actually this reduces the problem
> is reduced to simple objects which could be easily added, modified and
> discarded.
> We hope we put our thoughts on display understandably and looking forward
> hearing your thoughts.
> Andreas, Michael, Jakob and Kilian
> --
> SCHMUTTERER+PARTNER Information Technology GmbH
> Hiessbergergasse 1
> A-3002 Purkersdorf
> T   +43 (0) 69911127344
> F   +43 (2231) 61899-99
> mail to:

My LinkedIn profile:
My GoogleCode profile:
My Picasa:
My Tube:

View raw message