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: [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
