Daniel Kulp wrote: > Raymond, > > >>1) What's the use case to save a XMLDocument or DataObject to the >>XMLStreamWriter? If there's no such requirement, we can get rid of them. > > > Well, part of the work we are doing in Celtix is to allow the "databinding" > layer to write directly toward a XMLStreamWriter. I was hoping to use those > methods since that is ideal. > >
That's kind of what I had in mind - support for someone who wanted to push data into an output stream. >> 2) With the createStreamReader() method, we can easily pipe the reader to >>writer with a utility (Axiom has one). Here's the implementation in my >>latest patch. >> >> XMLStreamReader reader = createXMLStreamReader(document); >> new XMLStreamSerializer().serialize(reader, writer); // >>XMLStreamSerializer is the utility to pull events from the reader and dump >>them into the writer > > > What is the performance impact of doing that? I'm OK with doing something > like that (and maybe even making the mentioned save() and saveObject() > methods do that) if there isn't a major performance issue with doing that. > > Basically, the goal is to get the objects written out to a stream as quickly > as possible. If "reading events from one stream and pumping them to the > output stream" isn't too bad, I'm OK with it. But if there is a performance > impact of doing that, then I would suggest leaving the ability to write > directly to the XMLStreamWriter. > The biggest performance concern I would have is if this implementation needed to create a Thread to drive the event pump. A secondary concern would be if this created a lot of objects for the various read events e.g. does pushing text mean that an additional String or char[] instance is created? Finally, is there any downside to providing the API call? It sounds like it was something that fitted Dan's model. -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
