[Axis2] MTOM/SMTP ? Re: identifying MTOM/XOP

[Aleksander Slominski <as...@cs.indiana.edu>]

Dasarath Weeratunge wrote:

>--- Eran Chinthaka <ch...@opensource.lk> wrote:
>  
>
>>Hi Alek, Dasarath,
>>
>>
>>+1. But I know about HTTP case. How about other
>>transports like SMTP, TCP,
>>etc., ?? Can we identify this in other transports as
>>well.
>>    
>>
>
>SMTP is clearly out for optimized content since it is
>text only. U cannot send binary via SMTP.
>  
>
of course you can. 8bit encoding of emails with mime/multipart is 
supported for long time - am i wrong?

i see no reason why MTOM can not work over SMTP.

thanks,

alek

>--Dasarath
>
>
>
>
>  
>
>>>>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. 
>>>      
>>>
>>+1
>>
>>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.
>>>      
>>>
>>Small addition to Dasarath's question.
>>IMO, once data has been read from the message
>>through the data handlers,
>>OMBlob must store it. This is useful in async case.
>>But the problem is how
>>can OMBlob store that. If it tries to hold it in the
>>memory, then I think we
>>gonna have problem there.
>>
>>So what we can we do with attachments once they are
>>being read ??
>>
>>Thankx,
>>-- Chinthaka
>>
>>    
>>
>>>thanks
>>>
>>>--Dasarath
>>>
>>>
>>>      
>>>
>>>>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!
>>    
>>
>>>http://smallbusiness.yahoo.com/resources/
>>>      
>>>
>>
>>
>>    
>>
>
>
>		
>__________________________________ 
>Do you Yahoo!? 
>Yahoo! Small Business - Try our new resources site!
>http://smallbusiness.yahoo.com/resources/ 
>  
>


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