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 <[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
smime.p7s
Description: S/MIME cryptographic signature
