मैं एंड-यूजर डिवाइस और सर्वर के बीच मेटाडेटा को सिंक करने के लिए उच्च स्तरीय एप्लिकेशन प्रोटोकॉल को डिजाइन करने के बारे में सबसे अच्छा विचार करने के बारे में मार्गदर्शन की तलाश में हूं।डिवाइस और सर्वर के बीच मेटाडेटा सिंकिंग के लिए उच्च स्तरीय एप्लिकेशन प्रोटोकॉल और डेटा प्रारूप कैसे डिज़ाइन करें?
मेरा लक्ष्य: उपयोगकर्ता किसी भी डिवाइस या वेब पर एप्लिकेशन डेटा से सहभागिता कर सकता है। इस प्रोटोकॉल का उद्देश्य सर्वर के माध्यम से दूसरे एंडपॉइंट्स पर एक एंडपॉइंट पर किए गए परिवर्तनों को संवाद करना है, और यह सुनिश्चित करना है कि सभी डिवाइस एप्लिकेशन डेटा की एक सतत तस्वीर बनाए रखें। यदि उपयोगकर्ता एक डिवाइस या वेब पर परिवर्तन करता है, तो प्रोटोकॉल डेटा को केंद्रीय भंडार में धक्का देगा, जहां से अन्य डिवाइस इसे खींच सकते हैं।
कुछ अन्य डिजाइन विचार:
- मैं इसे "मेटाडाटा को सिंक करना" क्योंकि पेलोड काफी छोटा हो जाएगा, वस्तु आईडी और उन आईडी के बारे में छोटे मेटाडाटा के रूप में कहते हैं। जब क्लाइंट एंडपॉइंट्स इस प्रोटोकॉल पर नए मेटाडेटा को पुनर्प्राप्त करते हैं, तो वे इस मेटाडेटा के आधार पर बाहरी ऑब्जेक्ट डेटा को बाहरी स्रोत से प्राप्त करेंगे। "असली" ऑब्जेक्ट डेटा प्राप्त करना गुंजाइश से बाहर है, मैं केवल मेटाडेटा को सिंक करने के बारे में बात कर रहा हूं।
- ट्रांसलोड कंटेनर के लिए परिवहन और जेएसओएन के लिए HTTP का उपयोग करना। प्रश्न मूल रूप से जेएसओएन पेलोड स्कीमा को सर्वोत्तम तरीके से डिज़ाइन करने के तरीके के बारे में है।
- मैं चाहता हूं कि यह वेब पर और डेस्कटॉप और मोबाइल उपकरणों पर लागू और बनाए रखना आसान हो। सबसे अच्छा तरीका सरल टाइमर- या घटना-आधारित HTTP अनुरोध/प्रतिक्रिया किसी भी लगातार चैनल के बिना लगता है। इसके अलावा, आपको इसे पढ़ने के लिए पीएचडी नहीं होना चाहिए, और मैं चाहता हूं कि मेरी कल्पना 2 पृष्ठों पर फिट हो, 200 नहीं।
- प्रमाणीकरण और सुरक्षा इस प्रश्न के दायरे से बाहर है: मान लीजिए कि अनुरोध सुरक्षित और प्रमाणित हैं।
- लक्ष्य डिवाइस पर डेटा की अंतिम स्थिरता है, यह पूरी तरह रीयलटाइम नहीं है। उदाहरण के लिए, ऑफ़लाइन होने पर उपयोगकर्ता एक डिवाइस पर परिवर्तन कर सकता है। ऑनलाइन फिर से जाने पर, उपयोगकर्ता स्थानीय परिवर्तनों को धक्का देने और दूरस्थ परिवर्तनों को पुनर्प्राप्त करने के लिए "सिंक" ऑपरेशन करेगा।
- कहा करने के बाद कि, प्रोटोकॉल ऑपरेशन के ये दोनों ही मोड का समर्थन करना चाहिए:
- एक डिवाइस पर खरोंच से शुरू, पूरे मेटाडाटा चित्र
- "सिंक के रूप में तुम जाओ" खींचने के लिए सक्षम होना चाहिए। दो उपकरणों के साथ-साथ डेटा को देखने और परिवर्तन करने पर, उन परिवर्तनों को छोटे व्यक्तिगत संदेशों के रूप में धक्का देना आसान होना चाहिए, जो अन्य डिवाइस निकट-वास्तविक समय प्राप्त कर सकते हैं (जब यह सिंक के लिए सर्वर से संपर्क करने का निर्णय लेता है)।
एक ठोस उदाहरण के रूप में, आप ड्रॉपबॉक्स के बारे में सोच सकते हैं (यह है कि मैं क्या नहीं पर काम कर रहा हूँ, लेकिन यह मॉडल समझने में मदद करता): उपकरणों की एक श्रृंखला पर, उपयोगकर्ता एक प्रबंधन कर सकते हैं फाइलें और फ़ोल्डर्स- उन्हें चारों ओर ले जाएं, नए बनाएं, पुराने लोगों को हटाएं आदि। और मेरे संदर्भ में "मेटाडेटा" फ़ाइल और फ़ोल्डर संरचना होगी, लेकिन वास्तविक फ़ाइल सामग्री नहीं होगी। और मेटाडाटा फ़ील्ड फ़ाइल/फ़ोल्डर नाम और संशोधन के समय जैसे कुछ होंगे (सभी उपकरणों को संशोधन के समान समय को देखना चाहिए)।
एक और उदाहरण IMAP है। मैंने प्रोटोकॉल नहीं पढ़ा है, लेकिन मेरे लक्ष्य (शून्य वास्तविक संदेश निकाय) समान हैं।
Feels की तरह दो भव्य दृष्टिकोण यह कैसे किया जाता देखते हैं:
- व्यवहार संदेशों। सिस्टम में प्रत्येक परिवर्तन डेल्टा के रूप में व्यक्त किया जाता है और अंतराल उन डेल्टा के साथ संवाद करता है।उदाहरण: डीवीसीएस परिवर्तन।
- REST: व्यक्तिगत परमाणु परिवर्तनों के बारे में चिंता किए बिना ऑब्जेक्ट ग्राफ़ को पूरी तरह से या आंशिक रूप से संचारित करना।
संपादित करें: कुछ उत्तर ठीक ही कहते हैं कि काफी अच्छा सुझाव देने के लिए अनुप्रयोग के बारे में पर्याप्त जानकारी नहीं है। ऐप की सटीक प्रकृति विचलित हो सकती है, लेकिन एक बहुत ही बुनियादी आरएसएस रीडिंग ऐप एक अच्छा पर्याप्त अनुमान है। तो आइए मान लें कि ऐप स्पेक निम्न है:
- दो कक्षाएं हैं: फ़ीड्स और आइटम।
- मैं फ़ीड्स जोड़, नाम बदल और हटा सकता हूं। फ़ीड जोड़ना इसमें सदस्यता लेता है और उस फ़ीड के लिए आइटम प्राप्त करना शुरू करता है। मैं यूआई में फीड डिस्प्ले ऑर्डर को भी पुन: व्यवस्थित कर सकता हूं।
- जैसा कि मैंने आइटम पढ़े हैं, उन्हें पढ़ने के रूप में चिह्नित किया गया है। मैं उन्हें अपठित नहीं कर सकता या उनके साथ कुछ और नहीं कर सकता।
- ऊपर के आधार पर, ऑब्जेक्ट मॉडल है:
- "फ़ीड" गुण होते हैं "Url", "DisplayName" और "displayOrder" (displayOrder फ़ीड के यूआई की सूची में फ़ीड के सूचकांक है, पुनर्व्यवस्था खिलाती स्थानीय रूप से बदलता है सभी फ़ीड्स का प्रदर्शन ऑर्डर ताकि इंडेक्स अद्वितीय और अनुक्रमिक बने रहें)।
- "आइटम" में "यूआरएल" और "अपठित" गुण हैं, और कई से एक संबंध "फ़ीड" (प्रत्येक आइटम एक फ़ीड में संबंधित है)। "यूआरएल" आइटम के लिए GUID के रूप में भी व्यवहार करता है।
- वास्तविक आइटम सामग्री प्रत्येक डिवाइस पर स्थानीय रूप से डाउनलोड की जाती है और सिंक का हिस्सा नहीं होती है।
इस डिजाइन के आधार पर, मैं मेरे ऐप एक डिवाइस पर सेट कर सकते हैं: फ़ीड का एक समूह जोड़ने के लिए, नाम बदलने और उन्हें पुन: व्यवस्थित, और उन पर कुछ आइटम है, जो तब अपठित के रूप में चिह्नित कर रहे हैं पढ़ें। जब मैं डिवाइस स्विच करता हूं, तो दूसरा डिवाइस कॉन्फ़िगरेशन को सिंक कर सकता है और मुझे उसी नाम, ऑर्डर और उसी आइटम को पढ़ने/अपठित राज्यों के साथ एक ही फ़ीड सूची दिखा सकता है।
(अंत संपादित करें)
मैं जवाब में चाहते हैं क्या:
- क्या महत्वपूर्ण मैं ऊपर से बाहर छोड़ दिया है? बाधाएं, लक्ष्य?
- इस पर कुछ अच्छी पृष्ठभूमि पढ़ने क्या है? (मुझे एहसास है कि यह कितना कंप्यूटर विज्ञान पाठ्यक्रम बहुत लंबा और विस्तार से बात करता है ... मैं कुछ क्रैश कोर्स या नगेट्स को देखकर इसे शॉर्ट-सर्किट करने की उम्मीद कर रहा हूं।)
- ऐसे प्रोटोकॉल के कुछ अच्छे उदाहरण क्या हैं मैं मॉडल के बाद मॉडल का उपयोग कर सकता हूं, या यहां तक कि बॉक्स का उपयोग भी कर सकता हूं? (मैं उल्लेख ड्रॉपबॉक्स और ऊपर IMAP ... मैं शायद IMAP आरएफसी पढ़ना चाहिए।)
1. हाँ, कि मैं क्या सोचा था, मैं पूरा मेटाडाटा का अनुरोध करता हूँ (जैसे कि नाम से जाना जाता बिंदु एक्स से आगे) है इस प्रोटोकॉल प्रस्ताव विनिर्देश पर एक नजर डालें। 2. हां, क्लाइंट नया डेटा प्राप्त कर सकता है जिसके लिए इसमें अभी तक मेटाडेटा नहीं है, तो उसके बाद क्लाइंट अनुरोध प्रासंगिक मेटाडेटा (जो उस बिंदु से मौजूद हो सकता है या नहीं भी हो सकता है) 3. हां, इसके लिए अलग मेटाडेटा भी हो सकता है डेटा, मुझे समय-समय पर आधारित कुछ प्राथमिकता होगी - नए – Jaanus