Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <49576FCD.60902@apache.org>
Date: Sun, 28 Dec 2008 13:23:41 +0100
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [C3] StAX research reveiled!
References: <49520644.30108@gmail.com> <4955F707.4020705@apache.org>
 <200812271413.43183.andreas.pieber@schmutterer-partner.at>
 <4956B9B2.7050300@apache.org> <495725CD.9050809@indoqa.com>
In-Reply-To: <495725CD.9050809@indoqa.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

<snip/>

Steven Dolg wrote:
> Basically you're providing a buffer between every pair of components 
> and fill it as needed.

Yes. Now this buffer will always contain a very limited number of 
events, corresponding to the result of processing an amount of input 
data that is convenient to process at once to avoid complex state 
management (e.g. an <i18:text> tag with all its children). And so most 
often, this buffer will contain just one event.

Think of it as being just a bridge between the writer view used by a 
producer and the reader view used by its consumer. These are in my 
opinion the most convenient views to write StAX components.

> But you need to implement both XMLStreamWriter and XMLStreamReader and 
> optimize that for any possible thing a transformer might do.
> In order to buffer all the data from the components you will have to 
> create some objects as well - I guess you will end up with something 
> like the XMLEvent and maintaining a list of them in the StaxFIFO.
> That's why I think an efficient (as in faster than the Event API)  
> implementation of the StaxFIFO is difficult to make.

It's certainly less trivial than maitaining a list of events, but should 
be doable quite efficiently by using an int FIFO (to store event types 
and attribute counts) and a String FIFO (for everything else). I'll try 
find a couple of hours to prototype this.

> On the other hand I do think that the cursor API is quite a bit harder 
> to use.
> As stated in the Javadoc of XMLStreamReader it is the lowest level for 
> reading XML data - which usually means more logic in the code using 
> the API and more knowledge in the head of the developer 
> reading/writing the code is required.
> So I second Andreas' statement that we will sacrifice simplicity for 
> (a small amount of ?) performance.

I understand your point, even if I don't totally agree :-) Now it should 
be mentioned that if even with events, my proposal still stands: just 
replace XMLStream{Reader|Writer} with XMLEvent{Reader|Writer}.

> The other thing is that - at least the way you suggested - we would 
> need a special implementation of the Pipeline interface.
> That is something that compromises the intention behind having a 
> Pipeline API.
> Right now we can use the new StAX components and simply put them into 
> any of the Pipeline implementations we already have.
> Sacrificing this is completely out of the question IMO.

Actually, I'm wondering if wanting a single API is not wishful thinking 
and will in the end lead to something that is overly abstract and hence 
difficult to understand and use, or where underlying implementations 
will leak in the high-level abstraction.

There is already some impedence mismatch appearing between pull and push 
in the code:
- a StAXGenerator has to call initiatePullProcessing() on its consumer, 
which in turn will have to call it on it's own consumer, etc until we 
reach the Finisher that will finally start pulling events. This moves a 
responsibility that belongs to the pipeline down to its components.
- an AbstractStAXProducer only accepts a StAXConsumer, defeating the 
idea of a unified pipeline implementation that will accept everything.

So we should either have several APIs specifically tailored to the 
underlying push or pull model, or make sure the unified API and its 
implementations accept any kind of component and set the appropriate 
conversion bridges between them.

Sylvain

-- 
Sylvain Wallez - http://bluxte.net