I got your points, Dan and Jeremy.
In the short term, we can implement the save() method with the reader to
writer utility. Performance wise, I don't think it would be too bad because
the reader is pulling events on demand.
The implementation can be optimized to navigate the DataObject tree directly
and dump nodes into the XMLStreamWriter if the quick way doesn't perform.
Thanks,
Raymond
----- Original Message -----
From: "Daniel Kulp" <[EMAIL PROTECTED]>
To: <[email protected]>
Cc: "Raymond Feng" <[EMAIL PROTECTED]>
Sent: Wednesday, June 07, 2006 3:10 PM
Subject: Re: XMLStreamHelper
Raymond,
IMHO, the XMLStreamWriter is a simple way to produce XML documents by
writing xml artifacts instead of string concation. For SDO, we already
have
XMLHelper.save(). What's the add-on value to go through the
XMLStreamWriter
layer? Can something take advantage of the result XMLStreamWriter?
One of the things Celtix/IONA is doing is creating "custom"
XMLStreamWriters
that output to things other than XML. One example that the apache Yoko
project is doing is to output to CORBA DynType things for making CORBA
invokations. The yoko project, in combination with the celtix binding
in
Tuscany, should allow tuscany apps to invoke on CORBA applications.
However, that would need the XMLStreamWriter (maybe XMLEventWriter) stuff
working.
Dan
Thanks,
Raymond
----- Original Message -----
From: "Daniel Kulp" <[EMAIL PROTECTED]>
To: <[email protected]>
Cc: "Raymond Feng" <[EMAIL PROTECTED]>
Sent: Wednesday, June 07, 2006 1:36 PM
Subject: Re: XMLStreamHelper
> 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.
>
>> 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.
>
> Thanks!
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194 F:781-902-8001
> [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
