Steven Dolg wrote:
Sylvain Wallez schrieb:
<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.
Well I don't see the problem with that.
From the pipeline's point of view those are normal components just
like all the other.
The pipeline was never intended to "care" about the internals of the
components - so why bothering that the StAXGenerator calls
"initiatePullProcessing" on its consumer instead of calling some other
method like e.g. "startDocument".
Hmm... the fact that every implementation has to copy/paste the exact
same call to initiatePullProcessing (or has extend a common abstract
class that does it) because the pipeline expects processing to be
started on the first component is a sign of a design problem to me.
Some responsibilities of the pipeline creep into its components because
the pipeline is too abstract, or because there's an intermediate
adaptation layer that's missing.
- an AbstractStAXProducer only accepts a StAXConsumer, defeating the
idea of a unified pipeline implementation that will accept everything.
The idea was to have pipelines being capable of processing virtually
any data.
But that is not the same as combining components in an arbitrary way,
e.g. there is no sense in linking a FileGenerator with an (not yet
existing) ImageTransformer based on Java's Imaging API.
The components must be "compatible" - that is they must understand the
data they exchange with each other.
We may however provide some adapters/converters to make certain
"types" of components compatible, e.g. SAX <--> StAX.
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.
As I tried to state above: that will not be possible for every
conceivable combination of components.
At least not when thinking beyond XML - which I do.
Again I doubt of the real value of a common unified pipeline if all the
responsibility of ensuring proper compatibility between components
(including possible data conversion) is delegated to components. This
leaves a lot of complexity to component implementers (except in the
simple straightforward push scenario), and the features of the pipeline
will be limited to linking the components together and caching.
Furthermore, people will have to take great care of choosing components
that fit together, or they will get exceptions at pipeline execution
time. Hmm... reminds me of some criticism about the StAX stream API :-D
So let's agree that we disagree. I'll see what you guys come up with and
hope I'll change my mind then.
Sylvain
--
Sylvain Wallez - http://bluxte.net
