एमएस ऑफिस 2010 + SharePoint 2010 में सहयोग तंत्र: प्रोटोकॉल और पैकेज

सह-लेखन तंत्र एमएस ऑफिस 2010 और SharePoint 2010 की रिलीज़ के साथ दिखाई दिया। कई लोग प्रकट कार्यक्षमता को "लंबे समय से प्रतीक्षित" के रूप में कहते हैं, वास्तव में, इसका उपयोग करने में असमर्थता का कोई मतलब नहीं है। लेकिन यह लेख चर्चा करेगा कि यह तंत्र कैसे काम करता है और इससे क्या लाभ हो सकते हैं। अंत में गतिविधि के लिए एक नया क्षेत्र!

दिलचस्प उपयोगकर्ता

सबसे पहले, यह ध्यान देना आवश्यक है कि सह-लेखन तंत्र का काम कैसा दिखता है। इंटरनेट की विशालता की खोज करते हुए, यह पता चला कि उन्होंने पहले से ही पर्याप्त विस्तार से ऐसा किया है, इसलिए मैं खुद को दोहराऊंगा नहीं और सुझाव दूंगा कि मैं खुद को इससे परिचित करता हूं।

डेवलपर के लिए दिलचस्प

मेरे लिए यह समझना दिलचस्प था कि इस प्रक्रिया में उत्पन्न पैकेजों से उपयोगकर्ता की गतिविधियाँ कैसे संबंधित हैं। आगे के पैकेट पर कार्रवाई की पहचान करना सीखें। यह एक HTTP मॉड्यूल लिखकर कॉर्पोरेट पोर्टल पर उपयोगकर्ताओं (और मेरे मामले में, कर्मचारियों) के काम पर जानकारी एकत्र करने की अनुमति देगा। इस तरह की जानकारी उपयोगी हो जाती है, उदाहरण के लिए, प्रलेखन की तैयारी पर रूपांतरणों की संख्या बढ़ाने या काम की तीव्रता को ट्रैक करने के लिए। इसके अलावा, अभ्यास से पता चला है कि आउटगोइंग पैकेट के बजाय सर्वर में प्रवेश करने वाले पैकेट को सुनना अधिक कुशल और सुरक्षित है।

दस्तावेज़ कैशिंग के कारण, कार्य इस तथ्य से जटिल है कि MS-FSSHTTP प्रोटोकॉल के स्तर पर जानकारी अस्पष्ट रूप से उपयोगकर्ता के कार्यों को कुछ मामलों में निर्धारित करती है। उदाहरण के लिए, जब पहली बार कोई दस्तावेज़ खोलने की घटना होती है, तो एक दस्तावेज़ डाउनलोड किया जा रहा है और पैकेज विवरण से यह निर्धारित करना आसान है, और जब दूसरी बार कोई दस्तावेज़ खोला जाता है, तो दस्तावेज़ डाउनलोड नहीं किया जाता है, लेकिन सर्वर पर दस्तावेज़ के साथ कैश की तुलना में इसे खोला जाता है, हालांकि शब्दार्थ ये दो घटनाएं हैं दस्तावेज़ के साथ काम की शुरुआत का मतलब है।
सह-लेखन तंत्र Word 2010, Excel 2010, OneNote 2010, SharePoint कार्यस्थान 2010 SharePoint SharePoint 2010 या SharePoint Server 2010 के साथ सफलतापूर्वक काम करता है। यह विनिर्देशों में इंगित किया गया है।

प्रोटोकॉल और पैकेज

SharePoint सर्वर और MS Office 2010 उपयोगकर्ता के बीच सभी संचार MS-FSSHTTP (HTTP प्रोटोकॉल विशिष्टता पर SOAP के माध्यम से फ़ाइल सिंक्रनाइज़ेशन) और MS-FSSHTTPB (SOAP प्रोटोकॉल विशिष्टता के माध्यम से फ़ाइल सिंक्रनाइज़ेशन के लिए द्विआधारी अनुरोध) प्रोटोकॉल का उपयोग करके होता है।
अधिक सुविधा के लिए, मैं तुरंत प्रोटोकॉल के विवरण के लिए लिंक प्रदान करूंगा:
- MSDN -FSSHTTP के बारे में MSDN या MS-FSSHTTP विनिर्देश डाउनलोड करें
- MSDN -FSSHTTPB के बारे में MSDN या MS-FSSHTTPB विनिर्देश डाउनलोड करें

पैकेटों का आदान-प्रदान करते समय, MS-FSSHTTP प्रोटोकॉल उस इकाई के बारे में जानकारी प्रसारित करता है जिसके साथ काम शुरू होता है (इसका यूआरएल), लेखक के लिए जो इकाई के साथ काम करना शुरू कर देता है, और ऑपरेटिंग मोड (केवल पढ़ने और संपादित करने के लिए विभिन्न विशेषाधिकार की आवश्यकता होती है)। पैकेज का MS-FSSHTTP हिस्सा एक्सएमएल है, जो इस प्रोटोकॉल में कोई अनुग्रह नहीं जोड़ता है। पैकेज में XML उपविभाजनों को SubRequestToken पैरामीटर द्वारा क्रमांकित किया जाता है। यह DependOn पैरामीटर का उपयोग करके पैकेज की अखंडता की जांच करना संभव हो जाता है। MS-FSSHTTP और MS-FSSHTTPB प्रोटोकॉल के भीतर की इकाई को सेल कहा जाता है।
MS-FSSHTTP अनुरोध की संरचना निम्नलिखित पैटर्न में फिट होती है:

< s:Envelope xmlns:s ="http://schemas.xmlsoap.org/soap/envelope/" >
< s:Body >
< RequestVersion … > //
< RequestCollection … > // CorrelationID, guid
// .
< Request … > // URL
< SubRequest … /> //
</ SubRequest >
…
</ Request >
</ RequestCollection >
</ s:Body >
</ s:Envelope >



MS-FSSHTTP प्रोटोकॉल की संरचना पर कुछ स्पष्टीकरण:

< Request Url ="http://serverName/documentFullPath" RequestToken ="1" >


- प्रोटोकॉल पैकेज की अनिवार्य संरचना उस दस्तावेज को इंगित करती है जिससे अनुरोध को संबोधित किया गया है।

< SubRequest Type ="Coauth" SubRequestToken ="1" >


- सह-लेखक मोड की घोषणा, संलग्न टैग इंगित करता है कि किस प्रकार के सह-लेखक का उपयोग किया जाता है।

< SubRequest Type ="SchemaLock" SubRequestToken ="2" DependsOn ="1" DependencyType ="OnNotSupported" >


- डॉक्यूमेंट लॉक की उपस्थिति और इसके प्रकार को नेस्टेड टैग में इंगित करता है। जवाब में, सर्वर इंगित करता है कि क्या आप पहले दस्तावेज़ के साथ काम करना शुरू करते हैं या सह-लेखक के रूप में शामिल होते हैं।

< SubRequest Type ="Cell" SubRequestToken ="3" >


- दस्तावेज़ में बदलाव के बारे में प्रत्यक्ष जानकारी देता है। इसमें पैकेज का MS-FSSHTTPB भाग शामिल है।

< SubRequest Type ="WhoAmI" SubRequestToken ="2" />


- उपयोगकर्ता जानकारी।

उदाहरण MS-FSSHTTP एक पैकेट का हिस्सा उपयोगकर्ता से सर्वर (अनुरोध) तक:
पैकेज रिपोर्ट करता है कि दस्तावेज़ 2MB.docx को निर्दिष्ट पते पर एक्सेस किया जा रहा है और उपयोगकर्ता दस्तावेज़ प्राप्त करने के लिए तैयार है। बाइनरीडाटसाइज़ टैग के अंदर मूल्य की लंबाई इंगित करता है, अर्थात MS-FSSHTTPB भाग।

< s:Envelope xmlns:s ="http://schemas.xmlsoap.org/soap/envelope/" >
< s:Body >
< RequestVersion Version ="2" MinorVersion ="0" xmlns ="http://schemas.microsoft.com/sharepoint/soap/" />
< RequestCollection CorrelationId ="{010F340A-ACB5-442C-B11E-95CB877EEBA5}" xmlns ="http://schemas.microsoft.com/sharepoint/soap/" >
< Request Url ="http://moss14/Something/2MB.docx" RequestToken ="1" >
< SubRequest Type ="Cell" SubRequestToken ="1" >
< SubRequestData PartitionID ="383adc0b-e66e-4438-95e6-e39ef9720122" BinaryDataSize ="88" >
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCC
ACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
</ SubRequestData >
</ SubRequest >
< SubRequest Type ="WhoAmI" SubRequestToken ="2" />
< SubRequest Type ="Cell" SubRequestToken ="3" >
< SubRequestData PartitionID ="7808f4dd-2385-49d6-b7ce-37aca5e43602" BinaryDataSize ="88" >
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCC
ACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
</ SubRequestData >
</ SubRequest >
< SubRequest Type ="ServerTime" SubRequestToken ="4" />
< SubRequest Type ="Cell" SubRequestToken ="5" >
< SubRequestData GetFileProps ="true" BinaryDataSize ="88" >
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCC
ACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
</ SubRequestData >
</ SubRequest >
</ Request >
</ RequestCollection >
</ s:Body >
</ s:Envelope >



पैकेज अनुसंधान

विनिर्देशों का अध्ययन करते हुए, दस्तावेज़ के साथ काम की शुरुआत कैसे निर्धारित करें, इस पर कोई जवाब नहीं मिला। इसलिए, विभिन्न प्रकारों और दस्तावेजों के आकारों के साथ पैकेज के विश्लेषण के दौरान सामने आए संकेतों की जांच करना आवश्यक है, क्रैश-टेस्ट की व्यवस्था करें, अन्यथा किसी भी संकेत को सच कहना मुश्किल है, और काम उचित है। इसलिए, सभी पारंपरिक रूप से उपयोग किए जाने वाले प्रारूपों का विश्लेषण 30Mb तक के दस्तावेज़ आकार के साथ किया गया था।
विश्लेषण के परिणाम:

• अधिकतम पैकेट का आकार 3 एमबी से अधिक नहीं है, अर्थात 30 एमबी की फाइल 10 पैकेट के लिए स्थानांतरित की जाती है।
• केवल MS-FSSHTTP का विश्लेषण करके दस्तावेज़ के उद्घाटन (कैशिंग फ़ंक्शन के साथ अपलोड केंद्र के संचालन के कारण) के निर्धारण की समस्या को हल करना असंभव है, शेष क्रियाएं निर्धारित की जाती हैं।
• MS-FSSHTTP भाग के पैकेज moss14 / _vti_bin / cellstorage.svc / CellStorageService पर एक्सेस किए जाते हैं , बाकी इस कार्य में दिलचस्प नहीं हैं। यही है, यह HTTP अनुरोध का विश्लेषण करने के लिए एक फिल्टर होगा।

यह MS-FSSHTTPB प्रोटोकॉल से परिचित होने का समय है। डेटा को बेस 64 एनकोडिंग में प्रस्तुत किया गया है, और संरचना को निर्धारित करने के लिए एचईएक्स और बाइनरी कोड में अनुवाद करना आवश्यक है। इसके अलावा, बाइनरीडाटासाइज़ 88 के बराबर "खाली" MS-FSSHTTPB हिस्सा है, एक साफ MS-FSSHTTPB अनुरोध टेम्पलेट है। इसमें MS-FSSHTTPB अनुरोध के सभी खंड शामिल हैं, लेकिन अनुभागों में कोई जानकारी नहीं है।
यदि हम दो प्रोटोकॉल के बीच भूमिकाओं के वितरण के बारे में बात करते हैं, तो MS-FSSHTTP दस्तावेज़ के बाहर दिखाई देने वाली जानकारी का वर्णन करता है, अर्थात। वह सब जो हम फाइल को खोले बिना पता कर सकते हैं, और MS-FSSHTTPB दस्तावेज़ के अंदर क्या हो रहा है, दस्तावेज़ के किस स्थान पर क्या हो रहा है, इस बारे में सूचित करता है। इस प्रकार, पैकेज के MS-FSSHTTPB भाग में एन्कोड की गई जानकारी आपको सह-लेखकों से दस्तावेजों की स्थिति को सिंक्रनाइज़ करने की अनुमति देती है, दस्तावेज़ के केवल परिवर्तित भागों को प्रेषित करती है, जिससे नेटवर्क पर लोड को काफी कम किया जा सकता है। सच है, एक और कार्यान्वयन, मेरे दृष्टिकोण से, तर्कसंगत नहीं होगा।
MS-FSSHTTB प्रोटोकॉल-संचरित स्ट्रिंग पर विचार करें, जहां BinaryDataSize 88 है।
MS-FSSHTTP प्रोटोकॉल के XML टैग से मूल मान:

DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCCACUKaEPdwEWAgYAAwUAigICAADaAg<br>YAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==


डिकेड HEX कोड (देखें MS-FSSHTTPB विनिर्देश पी। 71-73):

0c 00 0b 00 //Protocol Version + Minimum Version
9c cf 29 f3 39 94 06 9b //Signature
06 02 00 00 //CellRequest Start
ee 02 00 00 //User Agent Start
aa 02 20 00 //User Agent GUID
7e b8 31 e7 45 dd aa 44 ab 80 0c 75 fb d1 53 0e //GUID
7a 02 08 00 //User Agent Version
94 29 a1 0f //Version
77 01 16 02 06 00 //User Agent End + SubRequest Start
03 05 //Request DI + Request Type
00 8a 02 02 00 //Priority + Query Changes
00 da 02 06 00 //Allow Fragments/Reserved + Query Changes Request Argument
03 00 00 //Include Storage Manifest + Cell ID
ca 02 08 00 //Query Changes Data Constraints
08 00 80 03 //Maximum Data Element
84 00 //Knowledge Start
41 //Knowledge End
0b 01 ac 02 //SubRequest End + Data Element Packege Start
00 55 03 01 //Reversed + Data Emlement Packege End + Cell Request End



अब, MS-FSSHTTPB का एक नया पुनरावृत्ति और विश्लेषण पहले किए गए विश्लेषण में जोड़ा गया है। उबाऊ उदाहरणों की खुशी के पाठक से वंचित, मैं विश्लेषण के परिणाम लाता हूं:

• 1. एक खाली पैकेट एक दस्तावेज़ प्राप्त करने के लिए तत्परता का संकेत है, जिसका अर्थ है कि यह सर्वर से दस्तावेज़ खोलने की घटना को निर्धारित करने में मदद करता है। फ़िल्टरिंग अनुरोध मॉड्यूल की मुख्य पंक्ति है:
  

  < SubRequestData GetFileProps ="true" BinaryDataSize ="88" >


  
  हालाँकि, यदि दस्तावेज़ अपलोड केंद्र में कैश किया गया था, तो बाइनरीडेटासाइज़ 88 से अधिक है, अर्थात्। यह एक खाली टेम्पलेट नहीं होगा, क्योंकि आपको वैधता के लिए दस्तावेज़ की जांच करने की आवश्यकता है। इस तरह के मामले की पहचान करने के लिए, एक अन्य विशेषता पाई गई।
  
• 2. अपलोड केंद्र में कैश्ड दस्तावेज़ की जाँच करने वाले पैकेज में इस सूची के पैरा 1 में निर्दिष्ट पंक्ति भी होती है। हालाँकि, बाइनरीडेटासाइज़ पैरामीटर का मान अधिक होता है, अपलोड सेंटर से चेक किया जाने वाला दस्तावेज़ जितना बड़ा होता है।

स्पष्टता के लिए, मैं इस तरह के पैकेज को पार्स करने का एक उदाहरण दूंगा।

< SubRequestData GetFileProps ="true" BinaryDataSize ="443" > DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+
9FTDnoCCACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEACYCIAD2NXoyYQc
URJaGUekAZnpNpAB4KCn1koJCYUFHqgOvQEOf2v3CNZY9eCgp9ZKCQmFBR6oDr0BDn9r9r
j3iPngoKfWSgkJhQUeqA69AQ5/a/fo+JkB4KCn1koJCYUFHqgOvQEOf2v0+
QGpBeCgp9ZKCQmFBR6oDr0BDn9r9gkGeQngmRlDki07gDrGjv1Ojie167QDOAngmua8bdL
Ef8U6jv1Ojie167QBmD1ETASYCIAATHwkQgsj7QJiGZTP5NMIdbAFw0Qz5C0E3b9GZRKbD
JyMu3KcRrXsAOAAyADkAMgBGADUAMgA5AC0ANgAxADQAMgAtADQANwA0ADEALQBBAEEAMA
AzAC0AQQBGADQAMAA0ADMAOQBGAEQAQQBGAEQAfQAsADMALAAzAAAAtRMBJgIgAA7pdjoy
gAxNud3zxlApQz5MASAoDLmvG3SxH/FOo79To4nteu1mDwClEwFBCwGsAgBVAwE= </ SubRequestData >



हेक्स डिकोड कोड:

0c 00 0b 00 //Protocol Version + Minimum Version
9c cf 29 f3 39 94 06 9b //Signature
06 02 00 00 //CellRequest Start
ee 02 00 00 //User Agent Start
aa 02 20 00 //User Agent GUID
7e b8 31 e7 45 dd aa 44 ab 80 0c 75 fb d1 53 0e //GUID
7a 02 08 00 //User Agent Version
94 29 a1 0f //Version
77 01 16 02 06 00 //User Agent End + SubRequest Start
03 05 //Request DI + Request Type
00 8a 02 02 00 //Priority + Query Changes
00 da 02 06 00 //Allow Fragments/Reserved + Query Changes Request Argument
03 00 00 //Include Storage Manifest + Cell ID
ca 02 08 00 //Query Changes Data Constraints
08 00 80 03 //Maximum Data Element
84 00 //Knowledge Start
\\ ,

26 02 20 00 //cell knowledge range
f6 35 7a 32 61 07 14 44 96 86 51 e9 00 66 7a 4d //GUID in cell knowlegde range
a4 00 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
c2 35 96 3d 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
ae 3d e2 3e 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
fa 3e 26 40 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
3e 40 6a 41 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
82 41 9e 42 78 26 46 50 e4 8b 4e e0 0e b1 a3 bf 53 a3 89 ed 7a ed 00
ce 02 78 26 //Pre DATA
b9 af 1b 74 b1 1f f1 4e a3 bf 53 a3 89 ed 7a ed //GUID before FROM number
00 66 0f //FROM number
51 13 01 26 02 20 00 13 1f 09 10 82 c8 fb 40 98 86 65 33 f9 34 c2 1d 6c 01 70 d1 0c f9 0b 41 37 6f d1 99 44 a6 c3 27 23 2e dc a7 11 ad
7b 00 38 00 32 00 39 00 32 00 46 00 35 00 32 00 39 00 2d 00 36 00 31 00 34 00 32 00 2d 00 34 00 37 00 34 00 31 00 2d 00 41 00 41 00 30 00 33 00 2d 00 41 00 46 00 34 00 30 00 34 00 33 00 39 00 46 00 44 00 41 00 46 00 44 00 7d 00 2c 00 33 00 2c 00 33 00 00 00
b5 13 01 26 02 20 00 0e e9 76 3a 32 80 0c 4d b9 dd f3 c6 50 29 43 3e 4c 01 20 28 0c //DATA changeset
b9 af 1b 74 b1 1f f1 4e a3 bf 53 a3 89 ed 7a ed //GUID before TO number
66 0f 00 //To number
a5 //Cell range End
13 01 //Cell End

//
41 //Knowledge End
0b 01 ac 02 //SubRequest End + Data Element Packege Start
00 55 03 //Reversed + Data Emlement Packege End + Cell Request End


सेल नॉलेज रेंज (MS-FSSHTTPB विनिर्देश पृष्ठ 37 देखें) की सामग्री को पार्स करना इतना सरल नहीं है। मैंने कोड में एक दोहराए जाने वाले डेटा + GUID बंडल को हाइलाइट किया था जो FROM को चर करने के लिए पारित किया गया था, लेकिन यह आवश्यक रूप से फ़ाइल के छोटे आकार के साथ पैकेज में मौजूद नहीं है, इसलिए इस डिज़ाइन को एक संकेत के रूप में नहीं माना जा सकता है। इस डिजाइन के शब्दार्थ के बारे में, रिस्पॉन्स पैकेज में एक समान डिजाइन का वर्णन किया गया है। आप यह समझाने की कोशिश कर सकते हैं कि रिक्वेस्ट पैकेज रिक्वेस्ट से कंस्ट्रक्शंस का इस्तेमाल क्यों करता है, लेकिन रिक्वेस्ट रिक्वेस्ट स्पेसिफिकेशन में इन स्ट्रक्चर्स का वर्णन क्यों नहीं किया गया, यह समझाना मुश्किल है। अब चर FROM और चर TO के बीच संलग्न डेटा पर ध्यान दें। यह वह जगह है जहां आधारशिला शब्द "7 बी 00" और "बी 5 13" के बीच है, सामग्री नियमित अभिव्यक्ति "\ w {2} [00]" में फिट होती है, लेकिन यह मत भूलो कि रिक्त स्थान केवल पठनीयता बढ़ाने के लिए निर्धारित हैं। यह लक्षण दस्तावेजों के साथ सभी परीक्षणों में खुद को साबित कर चुका है। हुर्रे साथियों! लेकिन आप रोक नहीं सकते हैं और इस तरह के डिजाइन के शब्दार्थ को भेदने की कोशिश कर सकते हैं। एक अनुभवी डेवलपर यह नोटिस कर सकता है कि UTF-16 (हेक्स) एन्कोडेड डेटा इस रूप में प्रस्तुत किया गया है। स्टॉक बदलना

7b 00 38 00 32 00 39 00 32 00 46 00 35 00 32 00 39 00 2d 00 36 00 31 00 34 00 32 00 <br>2d 00 34 00 37 00 34 00 31 00 2d 00 41 00 41 00 30 00 33 00 2d 00 41 00 46 00 34 00 30 00 34 00 <br>33 00 39 00 46 00 44 00 41 00 46 00 44 00 7d 00 2c 00 33 00 2c 00 33 00 00 00

UTF-16 (हेक्स) में हमें मिलता है

{8292f529-6142-4741-aa03-af40439fdafd},3,3

नतीजतन, यह पता चला है कि अध्ययन के तहत संरचना में मापदंडों को प्रेषित किया जाता है: एक GUID और दो संख्यात्मक पैरामीटर, जो संरचना को सार्थक बनाता है और यहां तक ​​कि डेवलपर को इसके शब्दार्थ को समझने की कोशिश करने की अनुमति देता है। हम मान सकते हैं कि GUID का उपयोग वैधता के लिए कैश्ड दस्तावेज़ की जाँच के लिए किया जाता है। इस संस्करण ने सभी संभावित आलोचनाओं को पीछे छोड़ दिया है और बहुत सफल लगता है!

निष्कर्ष

इस लेख में, मैंने प्रोटोकॉल स्तर पर MS Office 2010 + SharePoint 2010 में सह-लेखन तंत्र को उजागर करने का प्रयास किया। उम्मीद है कि मैं कुछ विशेषताओं को स्पष्ट रूप से समझाने में कामयाब रहा जो प्रोटोकॉल विनिर्देशों में शामिल नहीं हैं और जिन पर पहले ध्यान नहीं दिया गया था। यह ध्यान दिया जाना चाहिए कि MS-FSSHTTP और MS-FSSHTTPB प्रोटोकॉल के काम में मेरी व्यक्तिगत जांच के अंत के बाद से MSDN पर प्रलेखन काफी हद तक पूरक हो गया है।

सामान्य तौर पर, सह-लेखन का कार्य यूनिक्स-आधारित प्रणालियों में दस्तावेजों के संपादन पर काम के बुनियादी सिद्धांतों के समान है। अंतर इतना महत्वपूर्ण नहीं है कि सह-लेखन तंत्र को अभिनव कहा जाए। मैं इस विचार के साथ इस लेख को समाप्त करना चाहूंगा।

मैं आपको दिलचस्प शोध करना चाहता हूं!

इस लेख में स्रोत कोड को सोर्स कोड हाइलाइटर के साथ हाइलाइट किया गया था।