Project

General

Profile

ODF » History » Revision 19

Revision 18 (Adrian Georgescu, 11/05/2014 11:47 AM) → Revision 19/21 (Adrian Georgescu, 11/05/2014 11:47 AM)

h1. ODF integration 

 This documents layout the changes required to support rich-text collaborative editing. 

 It is unclear at this stage, the mechanics of WebODF. Important items to analyse are: 

  * Is a web server component required or not 
  * How to identify/mix multiple editing flows part of the same session 
  * How multi-party works as opposed to P2P 

 h2. Possible SDK changes 

 h3. Signaling 

 There is no need to alter anything related to SIP signalling. The SIP call id, which is unique for each session can be used as an identifier to group data related to same session inside the media streams.  

 h3. Media 

 Media requires reliable transport which in SIP can only be MSRP. This provides reliable end-to-end transmission, TLS encryption and NAT traversal. Optional, OTR end-to-end encryption can be used. 

 h4. Variant 1 

 This is by far the simplest way. Establish a standard MSRP chat stream and add _'application/odf+xml'_ to the list of supported payloads by subclassing the standard Chat stream from the SDK.  

 <pre> 
 class ODFChatStream(ChatStream): 
     accept_types = ['message/cpim', 'text/*', 'application/im-iscomposing+xml', 'application/odf+xml'] 
 </pre> 

 Then, during the session, send the data over the stream using: 

 <pre> 
 stream.send_message(data, content_type='application/odf+xml', timestamp=ISOTimestamp.now()) 
 </pre> 

 On the receiving end, in the notification handler for message received: end: 

 <pre> 
 def _NH_ChatStreamGotMessage(self, stream, data): 
     message = data.message 
     if message.content_type == 'application/odf+xml',: 
         # do something in the web view handling the editor 
         return 
 </pre> 


 Optionally, one can add an attribute to the MSRP stream to signal the support for this feature inside the media stream: 

 <pre> 
 class ODFChatStream(ChatStream): 
     accept_types = ['message/cpim', 'text/*', 'application/im-iscomposing+xml', 'application/odf+xml'] 
     def _create_local_media(self, uri_path): 
         local_media = super(BlinkChatStream, self)._create_local_media(uri_path) 
         local_media.attributes.append(SDPAttribute('features', 'odf-editor')) 
         return local_media 
 </pre> 

 After session negotiation, the clients can invoke their corespondent GUI elements related to the collaborative editing when detecting _odf-editor_ feature in the remote stream. This approach will work with any MSRP chat implementation, the data will piggy-back on top of an existent chat stream in a non-disruptive way, which makes development of other end-points easy as no internal mechanisms of SIP session session initiation must be done. 

 h4. Variant 2 

 Create a complete new media type based on MSRP protocol similar to file-transfer or screen sharing. See SIP SIMPLE Client SDK MSRP streams definition: 

 <pre> 
 sipsimple/streams/msrp.py 
 </pre> 

 Example of a new type of stream 

 <pre> 
 class ODFStream(MSRPStreamBase): 
     type = 'odf' 

     media_type = 'odf' 
     accept_types = ['application/odf+xml'] 
     accept_wrapped_types = ['*'] 
 </pre> 

 Once established, the MSRP stream can cary back and forth payloads of the types specified in the stream definition. Is up to the end-points to handle the actual payloads and match various files shared through this mechanism over the same session. The SIP session id can be used to group together various flows within the same stream. 

 This mechanism will require similar changes in other clients that wish to implement this feature, it is more complex but have the advantage that it can be negotiated by the use of a SIP Invite where the remote party can accept or reject the session request. 

 h3. Presence 

 Optionally, SIP end-points supporting this feature can advertise this capability by publishing it using the SIP SIMPLE Presence payload. For this, the end-point capabilities must be extended to support odf as a different media type. 

 <pre> 
 sipsimple/payloads/caps.py 
 </pre> 

 h2. GUI changes 

 The GUI must handle sessions for incoming and outgoing media stream defined above by creating its own controller that it is invoked either when negotiating the session, when a proper payload arrives over the chat channel or when user clicks in the GUI to start editing. 

 h2. Multi-party 

 SylkServer is the candidate for mixing media, it has built-in web server and MSRP switch capabilities.