Hi Alek, Dasarath, > > > --- Aleksander Slominski <[EMAIL PROTECTED]> wrote: > hi, > > > as i was asked to send it during irc chat but before > > Attachments Technologies (Canyang Kevin Liu and > > Sanjay Patil) > > > https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/ > documents/a1-8- > 4/Evolution%20of%20Web%20Services%20Attachments%20Technologies.article > > nice reference, thanks. > > > about identification: i thin that relying on > > transport to have > > type="application/xop+xml" in transport packaging > > should be enough (for > > HTTP it is: Content-Type: > > Multipart/Related;boundary=MIME_boundary; > > type="application/xop+xml";) > > So everyone is in agreement that transport should > identify whether the incoming message is an optimized > message or not, and use the appropriate OM builder to > construct the object model.
+1. But I know about HTTP case. How about other transports like SMTP, TCP, etc., ?? Can we identify this in other transports as well. > > > > > if XOP is detected then XOP Infoset is first created > > then it is later > > (at least in logical sense) resolved to "Original" > > Infoset - in infoset > > view there is no difference between BASE64 that is > > just text and one > > backed by binary attachments so there is need for OM > > API to identify > > In the present MTOM prototype, optimized binary > content is presented to the user *as is*(OMBlob). > However non-optimized binary is presented as text - > i.e. it does not differentiate between non optimized > bin content (base64 stuff) and normal text... it > cannot... why, there is no way to find out which one > is which. > > Further when programatically creating OM, if it is > allowed to specify through OMBlob whether the content > should be optimized or not, then it can give rise to > two different OM trees... all the OMBlobs that were > not optimized will be replaced by OMText at the > receiver. So one ans would be to use OMBlob for > optimized content ONLY. To send non-optimized content > use OMText. +1 OMText impl will be modified to have a > constructor which accepts a data handler and another > "getDataHandler" method. > > > (OMBlob?) and deal with very large attachments > > (stream in/out of files > > like in AXIS1 and/or make it extensible) > > One question is where to put the data handler once it > has been obtained from the underlying data stream? > Should it be stored in a field so that it can be > returned on subsequent calls to getDataHandler or > store to a temporary file. Small addition to Dasarath's question. IMO, once data has been read from the message through the data handlers, OMBlob must store it. This is useful in async case. But the problem is how can OMBlob store that. If it tries to hold it in the memory, then I think we gonna have problem there. So what we can we do with attachments once they are being read ?? Thankx, -- Chinthaka > > thanks > > --Dasarath > > > > > > Aleck > > > > -- > > The best way to predict the future is to invent it - > > Alan Kay > > > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Small Business - Try our new resources site! > http://smallbusiness.yahoo.com/resources/
