> 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";)
According to my knowledge the HTTP header will only contain the content-type header filed which will have value "multipart/related". the type="application/xop+xml" will come in the mime header. will they be acting as http headers, so that one can acces to them form transport. (Will there be any possibility of accesing this MIME header from the transport.) If not there will be a problem of identifyning the MTOM optimised XOP message. When we compare only the "multipart/relate" it'll guarantee only that this is a mime message. ws-attachments also use MIME??? I feel this can be problamatic in that sense. please correct me if I am wrong. > > > 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 Basically the decision between optimising or non-optimising will be notified by creating a OMBlob or a OMText. If one thinks of not optimising a OMBlob he should get the dataHandler from it & should create a OMText to replace it. > > OMText impl will be modified to have a > > > constructor which accepts a data handler and > > another > > > "getDataHandler" method. > > > +1 also a getDataHandler methode will be added to OMText > > > 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. or obtain it from MIME message through the MTOMBuilder whenever somebody calls the getDataHandler() of a OMBlob.???? In this case OMBlob will be not be storing DataHandler() or Object. > > IMO, once data has been read from the message > > through the data handlers, > > OMBlob must store it. This is useful in async case. Can somebody explain the functionality of DataHandler. Whether it actually reads and stores the data from mime stream or it just has a reference to the mime stream. further more refering to MTOM spec 4.3.1 "Implementations of this binding MUST enforce the restriction that XOP is not to be used with Infosets that contain element information items of name xop:Include (see [XML-binary Optimized Packaging] 3. XOP Infosets Constructs). " They have given two options to do at this point. V r planiing to generate a SOAP-FAULT . Comments??? thanx, Thilina Gunarathne
