Dasarath Weeratunge wrote:
--- 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.
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.
IMHO temporary file is fine solution if data form socket stream needs to
be read and flushed somewhere and AFAIK it is exactly what is done n AXIS1
alek
--
The best way to predict the future is to invent it - Alan Kay
