भविष्य की गतिविधियाँ - सत्र पोर्टेबल उपकरणों के बीच

यह पोस्ट आज लिखे इस लेख का अनुवाद है ।

पोस्ट के बारे में मुझे जो पहली चीज़ पसंद आई वह यह थी कि लेखक एक सामान्य डेटा वेयरहाउस के विचार के साथ आया था, और उसने क्रॉस-डिवाइस ट्रेंड पर छुआ है कि मैक / आईओएस में हाल के बदलावों का खुलासा नहीं हुआ है।

तो, चानी एमिटेज लिखते हैं।

मैंने इस पोस्ट को कई महीनों तक लिखने की कोशिश की, और आमतौर पर यह पूरी तरह से एक मूर्खता, या कुछ अन्य गलतफहमी के साथ समाप्त हो गया। इसलिए, स्कोर करने के लिए - मैं लिखना शुरू करूंगा, और फिर हम देखेंगे कि क्या होता है।

जो मैं बात करना चाहता था वह सत्र, एक्सएसपीएम, और वेलैंड था।



गतिविधियाँ (KDE क्रियाएँ) XSMP, X सत्र प्रबंधन प्रोटोकॉल, X-ray सत्र प्रबंधन प्रोटोकॉल का उपयोग करती हैं। वे इसका उपयोग खिड़कियों के समूहों को बचाने और पुनर्स्थापित करने के लिए करते हैं। पहले, इसका उपयोग लॉगिन पर एक सत्र को फिर से शुरू करने के लिए किया गया था। वास्तव में, यह प्रोटोकॉल आमतौर पर जितना सोचा जाता है, उससे कहीं बेहतर है और इसने दशकों से उत्कृष्ट सेवा की है - लेकिन समय बदल रहा है। यदि हम आगे बढ़ना चाहते हैं और कई उपकरणों के लिए सामान्य सत्रों की तरह शांत चीजें करते हैं, तो हमें कुछ नया चाहिए। गतिविधियों में भी, चूंकि वे अब एक्सएसपीएम की सीमाओं का विस्तार कर रहे हैं, ऐसे कई छिपे हुए घृणित बैसाखी हैं जिनकी आवश्यकता नहीं है।

इसलिए, महत्वपूर्ण बात यह है कि अगर हम पुराने, लेकिन विश्वसनीय, प्रौद्योगिकी को कुछ नया के साथ बदलना चाहते हैं, तो हम चाहते हैं कि यह कुछ नया न केवल बेहतर हो, बल्कि बहुत बेहतर हो। कुछ वास्तव में आगे बढ़ने लायक। XSMP में ऑटोसवे की कमी जैसी छोटी समस्याएं आसानी से हल हो जाती हैं; लेकिन एक बड़ी समस्या यह भी है कि XSMP प्रोसेस-बेस्ड है। सत्र कुंजी को व्यक्तिगत प्रक्रियाओं के लिए मैप किया जाता है, और जब आपको पुनर्प्राप्त करने की आवश्यकता होती है, तो यह एक विशिष्ट बाइनरी को कॉल करके होता है जिसमें सत्र कुंजी को एक तर्क के रूप में पारित किया जाता है। यह बुराई की जड़ है; शुरू करने के लिए, जब एक प्रक्रिया में कई विंडो (जैसे कंसोल) होती हैं, तो आप इन विंडो को कई सत्रों में सही ढंग से नहीं बिखेर सकते हैं - इसलिए, उपयोगकर्ता से इसे छुपाने के लिए गतिविधियाँ सभी प्रकार के मेल करना चाहिए। दूसरे, एक और भी बड़ी समस्या यह है कि इस तरह की विधि हास्यास्पद रूप से असहनीय और अपारदर्शी है। क्या होगा यदि प्रोग्राम बाइनरी कहीं स्थानांतरित हो गया है? क्या होगा यदि उपयोगकर्ता ने पुराने को बदलने के लिए एक वैकल्पिक एप्लिकेशन का उपयोग करना शुरू कर दिया? और, ज़ाहिर है, उसी प्रोग्राम को उपयोगकर्ता के मोबाइल फोन पर डेस्कटॉप कंप्यूटर पर स्थापित नहीं किया जाता है! यहां तक ​​कि अगर उसके पास मीगो पर फोन है, और वह अपने सभी मोबाइल और गैर-मोबाइल उपकरणों पर कैलिग्रा का उपयोग करता है, तो फोन पर द्विआधारी को अलग तरीके से कहा जाएगा। : पी

और हम क्या करते हैं? चलो संसाधनों का उपयोग करें! :) हम एक मानक प्रारूप में एक मानक जगह में डेटा स्टोर करेंगे। इसलिए कि इस सत्र में सत्र प्रबंधक "देखने के बजाय" / usr / bin / firefox, / usr / bin / konsole और / usr / bin / okular "देखता है," इस सत्र में वेब पृष्ठ X, Y और Z हैं पिछली बार फ़ायरफ़ॉक्स का उपयोग करते हुए इस उपकरण पर खोला गया था, एक्स और वाई के साथ एक खिड़की में समूहीकृत; पिछली बार के लिए दो टर्मिनलों का उपयोग किया गया था; और foo.pdf, पृष्ठ 3 पर खोला गया, जो पिछली बार इस उपकरण पर ओकुलर का उपयोग करके खोला गया था। " फिर यदि ओकुलर उपलब्ध नहीं है, तो वह सिस्टम से पीडीएफ खोलने के लिए एक कार्यक्रम का अनुरोध कर सकता है, और इसलिए, जब कोई उपयोगकर्ता फोन पर एक सत्र भेजता है, तो इससे कोई फर्क नहीं पड़ता कि फोन किसी अन्य पीडीएफ रीडर का उपयोग करता है, या यहां तक ​​कि फोन ब्राउज़र टैब का समर्थन नहीं करता है। इसके अलावा, यदि 3 पृष्ठों के बजाय 20 पृष्ठ खोले जाते हैं, तो फोन कह सकता है कि "ओह, यह थोड़ा बहुत है; मैं केवल पहले तीन खोलूंगा, और मैं एक विशेष स्थान पर सभी अन्य लोगों के लिए लिंक प्रदर्शित करूंगा। " या, उदाहरण के लिए, मैं सोच सकता हूं: "मैंने 'कुछ कचरा' नामक गतिविधि क्यों बनाई? नरक क्या है? ”, और मुझे इस सत्र को डाउनलोड किए बिना भी एक उत्तर मिल सकता है।

सिक्के का दूसरा पहलू यह है कि छोटी चीजें तय करती हैं। हाल ही में मैंने सुना कि OSX ने सत्रों के लिए गंभीर समर्थन जोड़ा; उन्होंने iPhone के उदाहरण से सीखा और अपने ज्ञान को डेस्कटॉप पर लागू किया। अब एक ऐसी प्रणाली है जिसके लिए यह बिल्कुल महत्वहीन है यदि आवेदन अचानक बंद हो जाता है - ऑपरेटिंग सिस्टम इसे जब चाहे तब मार सकता है - सत्र का समर्थन इतना अच्छा है कि आवेदन उसी स्थिति में ठीक हो जाएगा जैसे पहले था। लिनक्स में समान गुणवत्ता के सत्र के लिए समर्थन देखना बहुत अच्छा होगा; केडीई अनुप्रयोगों में, एक्सएसपीपी समर्थन पहले से ही बहुत अच्छा है, लेकिन यह और भी बेहतर हो सकता है (और इससे पहले, ऑटोसैव प्रोटोकॉल को लंबा रास्ता तय करना है)।

अब, XSMP की जगह कुछ पूरी तरह से नया विचार नहीं है। XSMP बौने काफी समय से इसे पसंद नहीं कर रहे थे, हालांकि मुझे नहीं लगता कि उनमें से किसी ने भी विकल्प बनाने के लिए कदम उठाए (और वैसे भी XSMP उनके उद्देश्यों के लिए उपयुक्त है)। जब मैंने नेपोमुक टीम के लोगों के साथ कई महीनों पहले उपकरणों के बीच सत्रों के हस्तांतरण के बारे में बात की थी, तो यह पता चला कि वे पहले से ही इसके बारे में सोच रहे थे - लेकिन फैसला किया कि इस तरह की परियोजना का राजनीतिक हिस्सा बहुत जटिल होगा। वे अभी भी सही हो सकते हैं - चलो देखते हैं। लेकिन एक कोशिश के काबिल। :)

तो कठिनाई क्या है, आप पूछें? यहां वह समस्या है जिसे मैं गतिविधियों के लिए XSMP विकसित करने में फंस गया हूं: एक नया प्रोटोकॉल होने का मतलब है कि आपको उस प्रोटोकॉल का समर्थन करने के लिए अनुप्रयोगों को समझाने की आवश्यकता है। XSMP के लिए समर्थन, हालांकि समस्याओं के बिना नहीं, हाल ही में व्यापक हो गया है और बहुत कम प्रतिरोध का कारण बना है। नया प्रोटोकॉल ... ठीक है, मुझे पूरा यकीन है कि वे केडीई में इसका इस्तेमाल करेंगे, लेकिन मैं चाहता हूं कि यह किसी दिन gtk पर, शुद्ध qt पर, meego पर, और कुटिल मालिकाना शिल्प पर भी अनुप्रयोगों का हिस्सा बन जाए। और अब यह एक वास्तविक परीक्षा है! :)

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

तो मेरे साथ कौन है? डेस्कटॉप समिट से कुछ ही दिन पहले बचे हैं, और, अचानक, मैं इसका आयोजक हूं (याहू!), और मैं ऊपर वर्णित विषयों पर चर्चा करना चाहूंगा। आखिरकार, यह कुछ के लिए एक शानदार जगह है जिसका उद्देश्य उपकरणों, डेस्कटॉप और जो कुछ भी आप चाहते हैं, के बीच पोर्टेबल होना है।

टीएल; डीआर: एक संसाधन-आधारित सत्र प्रोटोकॉल हमें वास्तव में शांत चीजें करने की अनुमति देगा, इसलिए XSMP को प्रतिस्थापित करना प्रयास के लायक है।

अब, मैं तकनीकी विवरणों में तल्लीन करना चाहता हूं (मेरे पास इस विषय पर एक पूरा काम लिखने के लिए पर्याप्त सामग्री है, अगर यह बहुत बुरा लेखक सिंड्रोम के लिए नहीं है ...)

...

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

ठीक है ... मैंने भंडारण सुविधाओं का बहुत अध्ययन नहीं किया है। आप इसे nepomuk / tracker / zeitgeist में, या kconfig जैसी पाठ फ़ाइलों में, या यहां तक ​​कि रजिस्ट्री (eek) में संग्रहीत कर सकते हैं - यह वास्तव में केवल महत्वपूर्ण है कि सिस्टम अपने कार्यों के साथ अच्छी तरह से मुकाबला करता है और डिवाइस पर सभी एप्लिकेशन इसका उपयोग करते हैं। यह पता लग सकता है कि विभिन्न उपकरणों के लिए अलग-अलग बैकेंड उपयुक्त हैं - मैंने अभी तक इसका पता नहीं लगाया है, और मैं विभिन्न दृष्टिकोणों के सकारात्मक और नकारात्मक पक्षों के बारे में कुछ जानकारी सुनना चाहूंगा। एप्लिकेशन नियमित रूप से कुछ डेटा - पेज सामान्य, फिल्म में स्थिति आदि को अपडेट करेंगे - इसलिए, मैं दक्षता के बारे में भी सुनना चाहूंगा।

कम से कम, मैंने डेटा प्रारूप का एक मोटा रेखाचित्र बनाया। संसाधनों का मुख्य भाग कुछ यूआरआई (आमतौर पर स्थानीय या http) और दस्तावेज़ के अंदर एक स्थिति होगा। URI कुंजी बन जाता है, और स्थिति फ़ील्ड में से एक बन जाती है ... अन्य फ़ील्ड वे विंडो होंगी जिनमें यह संसाधन स्थित है (अंत में, विंडो अभी भी विंडो मैनेजर की तार्किक इकाई बनी हुई हैं, और उनकी स्थिति और आकार महत्वपूर्ण सत्र डेटा हैं), अंतिम बार उपयोग किया गया अनुप्रयोग, प्रोग्राम के लिए अपने स्वयं के डेटा फ़ील्ड (अधिमानतः, छोटे से बेहतर), और संभवतः अन्य डिवाइसों से डेटा (उन समाधानों की सहायता के लिए जो डिवाइस अपने आप से सामना नहीं कर सकते हैं, या यदि सत्र कुछ उपकरणों में स्थानांतरित किया जाता है जहां ये डेटा वह होगा अर्थ जा सकती है)। खिड़कियों के लिए सत्र डेटा दर्ज किया जाएगा, शायद खिड़की प्रबंधक द्वारा ही ... वास्तव में, मुझे अच्छे डेटा संरचनाओं के साथ आने के लिए एक स्वच्छ बोर्ड और अधिक प्रोग्रामर की आवश्यकता है, यही कारण है कि मैं बर्लिन में ऐसा करने जा रहा हूं। और मुझे यकीन है कि कार्यान्वयन के दौरान भी ये निर्णय बदल जाएंगे :) शुरुआत के लिए, कम से कम कुछ संसाधन-आधारित संरचना का निर्माण करना महत्वपूर्ण है जो काम करेगा।

दूसरा भाग सत्र प्रबंधक है। यह एक कार्यक्रम है - सबसे अधिक संभावना है कि एक डेमॉन, लेकिन आवश्यक नहीं है - जो एक सत्र खोला जाने पर अनुप्रयोगों को लोड करता है और आवश्यक होने पर उन्हें बंद करने के लिए कहता है। यदि कोई संवादात्मक प्रक्रिया है ("क्या आप इस दस्तावेज़ को बचाना चाहते हैं?"), यह भी संसाधित किया जाना चाहिए। यह ksm- सर्वर अभी XSMP के लिए करता है। वास्तव में, इसमें अधिक समय नहीं लगेगा, अधिकांश भाग के लिए कॉन्फ़िगरेशन फ़ाइलों को पढ़ने और लिखने में लगेगा, लेकिन उपयोगकर्ता के साथ संचार का अनुरोध करने (सत्र को रोकते हुए) या यहां तक ​​कि इसे पूरी तरह से रद्द करने की अनुप्रयोगों की क्षमता से सब कुछ जटिल है।

तीसरा भाग पारदर्शी एपीआई है, वह हिस्सा जो अधिकांश डेवलपर्स देखेंगे। मैं चाहता हूं कि एपीआई अच्छा हो । मैं पिछड़े और आगे की अनुकूलता भी लेना चाहूंगा; कार्यान्वयन कीड़े या डिज़ाइन त्रुटियों को ठीक करने के अलावा, XSMP को कभी नहीं बदला गया है, लेकिन नया प्रोटोकॉल बदल जाएगा। अधिकांश अनुप्रयोगों में एक साझा गतिशील रूप से जुड़ा पुस्तकालय होगा, लेकिन क्या हमें सांख्यिकीय रूप से जुड़े होने की चिंता करनी चाहिए? सौभाग्य से, हम एक ऐसे डिजाइन के साथ आए जो ऐसे मामलों को बहुत अच्छी तरह से संभालता है। मुझे याद है dbus; वह एक बस प्रारूप का वर्णन करता है जो अनुप्रयोगों को हमेशा एक ही भाषा में संवाद करने की अनुमति देता है, लेकिन एक खामी है - वे इस प्रारूप में कभी सुधार नहीं कर सकते। : /

Dbus की बात करें, तो क्या यह उन चीजों में से एक है जो मुझे रुचिकर बनाती हैं, सत्र प्रबंधक और अनुप्रयोगों को एक दूसरे के साथ कैसे संवाद करना चाहिए? मुझे लगता है कि दक्षता के कारणों के लिए रिपॉजिटरी को जितना संभव हो सके सीधे लिखा जाना चाहिए, (एक साथ रिकॉर्डिंग संघर्षों को गायब कर दिया जाएगा, यदि बिल्कुल भी, और मैं एक साथ लिखने और पढ़ने के टकराव से समान होने की उम्मीद करता हूं)। हम प्रदर्शन में तेज कमी की तरह कुछ की उम्मीद कर सकते हैं यदि फ़ाइल सिस्टम बफर बहुत छोटा है; सबसे खराब स्थिति में, कल्पना करें कि हजारों आवेदन कैसे बिना किसी तुल्यकालन के हर 10 सेकंड में अपने राज्य को अपडेट करना शुरू करते हैं; यह पता चल सकता है कि प्रति सेकंड एक से अधिक लिखने का ऑपरेशन होता है। सौभाग्य से, कुछ, एक या दो अनुप्रयोग होंगे जो इस तरह के नियमित अपडेट करेंगे (आप केवल एक फिल्म देख सकते हैं, या यहां तक ​​कि जब आप पढ़ते हैं, तो केवल एक स्रोत से पृष्ठभूमि संगीत सुन सकते हैं), लेकिन फिर भी यह कुछ ऐसा है जिसे आपको बाद में सोचना चाहिए ।

उफ़, मैं थोड़ा भटका; सत्र प्रबंधक के साथ बातचीत पर वापस जाएं। जब मैंने उप-सत्र (यानी, गतिविधियां) का समर्थन करने के लिए किसमेर और केविन को अपडेट किया, तो मैं डब में टाइमआउट के साथ एक दलदल में फंस गया। सबसे अधिक संभावना है, मैं इस तरह से जाने वाला एकमात्र नहीं था, लेकिन मुझे कोई विकल्प नहीं पता है। XSMP कुछ प्रकार के प्राचीन प्रोटोकॉल का उपयोग करता है जिसे ICE कहा जाता है, जो X11 से कसकर बंधा हुआ लगता है; इस नाम के साथ कई प्रोटोकॉल हैं, इसलिए यह बहुत अप्रिय है। किसी भी मामले में, मैं X11 पर टाई को तोड़ना चाहता हूं, ताकि इसे वेटलैंड के साथ आसानी से किया जा सके - संवाद करने के लिए वे वहां क्या उपयोग करते हैं?

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

तो हमें वास्तव में किन अवसरों की आवश्यकता है?

- एप्लिकेशन या विंडो मैनेजर को खिड़कियों के आकार और स्थिति को रिकॉर्ड करना चाहिए। यदि अंत में एप्लिकेशन ऐसा करेगा, तो यह पुस्तकालय की मदद से पूरी तरह से स्वचालित रूप से होना चाहिए, और कुछ नहीं जो एप्लिकेशन डेवलपर्स को इसके बारे में सोचना चाहिए।
- अनुप्रयोगों को इस तथ्य को रिकॉर्ड करने की आवश्यकता होती है कि वे एक विशिष्ट विंडो में संसाधन प्रदर्शित करते हैं
- उन्हें यह भी दर्ज करने की आवश्यकता है कि उन्होंने इसे प्रदर्शित करना बंद कर दिया :)
- प्रदर्शन के समय खिड़की या संसाधन किसी विशेष सत्र से जुड़े होने चाहिए
- अनुप्रयोगों को यह कहना होगा कि उन्हें कब बंद होना चाहिए
- आवेदन सत्र डेटा से खुद को पुनर्प्राप्त करने में सक्षम होना चाहिए
- आवेदनों में एक सत्र में अपना स्वयं का गैर-मानक डेटा संग्रहीत करने का एक तरीका होना चाहिए

यह सिर्फ XSMP की शक्ति को कॉपी करने के लिए नींव है। वास्तव में कुछ अच्छा करने के लिए, हमें यह भी करना चाहिए:
- इन विंडो को कई सत्रों के बीच वितरित किया जाता है, तो आवेदन को ठीक से बताएं
- एप्लिकेशन को बताएं कि क्या यह पूरे सत्र को फिर से शुरू करना चाहिए या केवल इसका हिस्सा होना चाहिए
- साझा पोर्टेबल सत्र डेटा (जैसे दस्तावेज़ में एक स्थिति) को एक मानक स्थान पर संग्रहीत करने के लिए एप्लिकेशन को अनुमति दें और प्रोत्साहित करें, और ताकि कोई भी एप्लिकेशन इस डेटा का उपयोग कर सके

मुझे यकीन है कि मैंने कुछ चीजों को याद किया, लेकिन आप पहले से ही इस विचार को समझ गए :)

वास्तव में, एक चौथा भाग है: उपकरणों के बीच सिंक्रनाइज़ेशन। दो उपकरण अपने सत्र डेटा का आदान-प्रदान कैसे करेंगे? संसाधनों और संबंधित डेटा की एक सूची भेजना कुछ सरल लगता है, लेकिन कई विवरण हैं जिन्हें अभी भी संबोधित करने की आवश्यकता है - जिन संसाधनों को आपको अन्य डिवाइसों पर कॉपी करने की आवश्यकता है, उन्हें URI (फ़ाइल /home/chani/Documents/foo.pdf) को बदलने से कैसे निपटना है स्थिर कंप्यूटर एक पूरी तरह से अलग जगह पर फोन पर होगा) जब सिंक्रनाइज़ करने और संघर्षों को हल करने का प्रयास किया जाता है ... :) मुझे यकीन है कि ऐसे लोग हैं जो मेरे बारे में इससे कहीं अधिक समझते हैं। और, एक बोनस के रूप में, परिणामी सिंक्रनाइज़ेशन कोड वितरण के बीच स्थानांतरण के लिए तैयार होना चाहिए, और यहां तक ​​कि, कुछ समय के लिए, डेटा संग्रहीत करने के लिए सबसे अलग बैकएंड के बीच।

इस सब की प्राप्ति में समय लगेगा, अनुकूलन में और भी अधिक समय लगेगा। यह कई वर्षों के लिए एक परियोजना है। लेकिन, अगर लोग वास्तव में कुछ चाहते हैं, तो यह सब काफी संभव है।