cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <steven.d...@indoqa.com>
Subject Re: [cocoon3] Stax Pipelines
Date Wed, 03 Dec 2008 09:56:35 GMT
Thorsten Scherler schrieb:
> El mié, 03-12-2008 a las 08:56 +0100, Sylvain Wallez escribió:
>   
>> Andreas Pieber wrote:
>>     
> ...
>   
>>> One big "problem" in this approach is that the "flow direction of events" is

>>> completely inverted. This means that StAX and SAX components would not be able

>>> to work "directly" together. But also in a push-pull approach a conversion 
>>> between StAX and SAX events have to be done and further more this problem could

>>> be tackled by writing a wrapper or adapters around the SAX components and add

>>> them to an StAX pipe.
>>>   
>>>       
>> Absolutely. Converting Stax to SAX is fairly trivial, but the other way 
>> around requires buffering or multithreading. Have you looked at 
>> Stax-Utils [1]? It contains many classes to ease the SAX <-> Stax 
>> translation.
>>
>>     
>
> I lately played around (and still do) with such approach in the forrest
> dispatcher rewrite [3]. I am using Axiom which is a quite interesting
> approach and maybe worth looking into [4]. However I did some profiling
> and for the dispatcher the old SAX approach had been ways faster.
>   
We started with an evaluation of some StAX implementations including 
Axiom, WoodStox and the reference implementation.
However quite early we felt that the DOM-like approach of Axiom is not 
ideally suited for our current phase.
I'm quite sure that there are occasions where Axiom can be really 
charming, but I believe there are too many premises required to 
efficiently use it (e.g. you will want to be sure that the XML data is 
not too large). But if you have some complex transformation that appear 
to difficult to be implemented in a one-pass approach Axiom could 
probably do the trick.
I'm sure we will explore this idea at a later time, though...

> However this is due to the buffering issue pointed out by Sylvain which
> [5] is not solving at all. Brings me back to do a sax (+stax) approach
> again (the other class in the package).
>
> I am really exited about this thread. :)
>   
I must admit that it got me all excited by now, too.

Yesterday, I did a very minimalistic POC, just to make sure our current 
approach is not missing any major point.
I have to say I was simply amazed how easy state handling can be when 
using StAX compared to SAX and I'm very confident that we came up with a 
pretty thorough concept.

After all, we tortured our poor students more than a month with 
evaluating implemenations, writing uses cases - outside Cocoon! - using 
both SAX and StAX, before even "allowing" them to think about how to 
integrate this into Cocoon.
I believe this was necessary to fully understand the differences between 
StAX and SAX and - even more important - the different usage patterns 
associated with them.
And I'm sure this allows us now to fully reap the benefits of this API.

Well, I can't wait to see the first components ...
> salu2
>
> ...
>   
>> [1] http://stax-utils.dev.java.net/
>> [2] http://www.flickr.com/services/api/response.rest.html
>>     
>
> [3]
> https://svn.apache.org/repos/asf/forrest/branches/dispatcher_rewrite/plugins/org.apache.forrest.plugin.internal.dispatcher
> [4] http://ws.apache.org/commons/axiom/OMTutorial.html
> [5]
> https://svn.apache.org/repos/asf/forrest/branches/dispatcher_rewrite/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherWrapperTransformer.java
>   


Mime
View raw message