axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: [Axis2] identifying MTOM/XOP
Date Thu, 10 Mar 2005 17:47:26 GMT
thilina Gunarathne wrote:

>>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.
>  
>
actually i am pretty sure it comes in Content-type?

where do you have it coming in other places?

>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.)
>  
>
transport can probably be configured to create special builder when 
Multipart and type="application/xop+xml" is encountered?

>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.
>  
>
yes this is the problem and unless proven wrong i would say that 
checking type="application/xop+xml" is the right way to do this?

>  
>
>>>>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.
>  
>
i think OMBlob should implement OMText so code that do not cae abotu 
"blobs" can treat them as text neodes with BASE64 and pay dearly price 
of converting binary into BASE64 - but that is developer decision and 
may be just fine for simplicity and for small binary payloads...

>  
>
>>>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.
>  
>
i have no opinion - looks implementation detail - how doing or not doing 
this affects Infoset view?

>
>  
>
>>>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.
>  
>
it should work as reference

>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???
>  
>
i think that this restriction is in place to distinguish XOP Infoset and 
"Original" Infoset.

alek

-- 
The best way to predict the future is to invent it - Alan Kay


Mime
View raw message