You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Andreas Pieber <an...@schmutterer-partner.at> on 2008/12/10 12:24:55 UTC
Our idea for simple StAX workflows
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: andreas.pieber@schmutterer-partner.at
Re: Our idea for simple StAX workflows
Posted by Reinhard Pötz <re...@apache.org>.
Andreas Pieber wrote:
<snip/>
> First of all our implementation does not change any of the existing cocoon
> interfaces.
For those who haven't read the previous messages about Stax, I want to
add that Andreas is talking about 'Cocoon 3'.
--
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 reinhard@apache.org
________________________________________________________________________
RE: Our idea for simple StAX workflows
Posted by Jakob Spörk <ja...@gmx.at>.
Hello Simon,
My name is Jakob Spoerk and I'm also member of the student group working on the Cocoon 3 StAX pipeline.
Of course we are also thinking about combining SAX and StAX components because this allowa to extend existing pipelines with StAX components and - what is even more important - it allows to use SAX where this is better and StAX where this is better, so to use the best of both worlds.
Our main priority at the moment lies on StAX-only pipelines, because we can then build on this implementation to allow the combination with SAX. At the current stage, we don’t plan on having an automatism that allows to throw different SAX and StAX components in one pipeline and "adapters" are set automatically between them. The developer will have to do this explicitly. Our first idea at this topic is to build in a first step some kind of "envelope" that is itself a StAX component but can be filled with one or more SAX components. The StAX->SAX interface shouldn’t be that problem, because after pulling an event from the component before, the envelope just fire the corresponding event in the first SAX component. The other end of the envelop will require more "work", because we can't expect the event to really pass the SAX components because maybe it is discarded or more events are build out of one, but we are very optimistic to find also a simple way for this transformation. Using StAX components in SAX pipelines will also be interesting, but at the moment, our priority lies on StAX-only pipelines :) and we hope to present you a first prototype in the following days.
Best regards,
Jakob
>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!
>Simone
>
>2008/12/10 Andreas Pieber <an...@schmutterer-partner.at>:
>> 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: andreas.pieber@schmutterer-partner.at
>>
--
My LinkedIn profile: http://www.linkedin.com/in/simonetripodi
My GoogleCode profile: http://code.google.com/u/simone.tripodi/
My Picasa: http://picasaweb.google.com/simone.tripodi/
My Tube: http://www.youtube.com/user/stripodi
My Del.icio.us: http://del.icio.us/simone.tripodi
Re: Our idea for simple StAX workflows
Posted by Simone Tripodi <si...@gmail.com>.
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!
Simone
2008/12/10 Andreas Pieber <an...@schmutterer-partner.at>:
> 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: andreas.pieber@schmutterer-partner.at
>
--
My LinkedIn profile: http://www.linkedin.com/in/simonetripodi
My GoogleCode profile: http://code.google.com/u/simone.tripodi/
My Picasa: http://picasaweb.google.com/simone.tripodi/
My Tube: http://www.youtube.com/user/stripodi
My Del.icio.us: http://del.icio.us/simone.tripodi