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 <[EMAIL PROTECTED]>: > 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] > -- 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
