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
