axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dasarath Weeratunge <>
Subject Re: [Axis2] identifying MTOM/XOP
Date Thu, 10 Mar 2005 09:47:45 GMT

--- Aleksander Slominski <> wrote:

> as i was asked to send it during irc chat but before
> Attachments Technologies (Canyang Kevin Liu and
> Sanjay Patil)

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.

> 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. 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.



> 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! 

View raw message