Hi, > May be i am missing something...the difference in my mind is a person > implementing a databinding layer should be able to access the > attachements without having to build the om tree. straight from stax > to java objects with no om and use whatever they need to store the > attachments byte arrays or data handlers or some databinding specific > construct. IMO this is possible even in the current implementation. They can easily use the functionality provided by the MIMEHelper.. I accept that we need to come up with a much better API with much more functionality.. Specially when talking about the outflow...
<quoting my earlier post> But the OM will **not** get created irrespective of whether the Caching is ON or OFF.. Remaining InputStream for the Envelope is buffered in a File or in memory as a FileDataSource of MemoryDataSource depending on the size.. </quote> As i have mentioned in my earlier post in this thread, MIME parser operates one level lower to the stax+OM and we are buffering the envelope at that level whenever we need to access the attachments... Worried whether I'm making any sense.... ~Thilina > > -- dims > > On 3/31/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > > On Fri, 2006-03-31 at 15:35 +0600, Thilina Gunarathne wrote: > > > <quote Glen> > > > What we want is a "thingy" which can be stored away and LATER used to > > > get the real attachment data after all XML pulling is done > > > </quote> > > > > > > IMHO we are doing the exactly the same thing using OMTexts.. Currently > > > we are doing this with more flexibility and of course with a catch.. > > > Flexibility is given by allowing the users to get the real attachment > > > data if they wish while pulling the XML.. Catch is that we are > > > buffering the SOAP Envelope in the MIME Parser which is underneath the > > > StaxReader... > > > > Thilina, I don't see this as a catch - isn't it impossible to get to any > > attachments without buffering the SOAP envelope? Or are you thinking > > about reading the SOAP envelope and buffering it IFF someone actually > > refers to an attachment? > > > > While that's interesting in theory, whoever sent the attachment more > > often than not expected the other end to read the darn thing. I don't > > see the point of that potential optimization. Maybe I'm missing > > something. > > > > Sanjiva. > > > > > > > -- > Davanum Srinivas : http://wso2.com/blogs/ > -- "May the SourcE be with u" http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ http://www.bloglines.com/blog/Thilina
