डिज़ाइन सिद्धांत¶
सात नियम जिनका कोड पालन करता है, हर एक के साथ वे पेज और फ़ैसलों के रिकॉर्ड जहाँ वह दिखता है। यह पेज पढ़ें ताकि समझ आए कि Evey जैसा बर्ताव करता है वैसा क्यों करता है, इससे पहले कि आप पढ़ें कि वह कैसे बना है (आर्किटेक्चर) या कोई ढाँचे वाला फ़ैसला क्यों लिया गया (फ़ैसलों के रिकॉर्ड)। जब दो सिद्धांत टकराते हैं, तो इस सूची में जो पहले आता है, उसे प्राथमिकता मिलती है।
| सिद्धांत | कहाँ दिखता है | किसने तय किया |
|---|---|---|
| 1. जब पहुँच जाँची न जा सके, तो मना कर दी जाती है | अभिभावक नियंत्रण, प्लगइन इंस्टॉल, रिमोट एक्सेस | ADR-0026 |
| 2. बाहरी कोड पर भरोसा नहीं किया जाता, उसे सीमित रखा जाता है | प्लगइन सैंडबॉक्स | ADR-0012, ADR-0014 |
| 3. जब भी हो सके, असली फ़ाइल दी जाती है | प्लेबैक का फ़ैसला | ADR-0030 |
| 4. फ़ैसले साबित हुई बातों पर टिके हैं, नामों पर नहीं | कास्ट करना, हार्डवेयर एक्सेलेरेशन | ADR-0029 |
| 5. एक प्लेबैक, एक फ़ैसला | प्लेबैक की योजना, स्ट्रीम जानकारी | ADR-0030, ADR-0024 |
| 6. सर्वर खुद को मशीन के हिसाब से ढालता है | calibration, बैकग्राउंड का काम | - |
| 7. कम सेटिंग्स, हर एक एक ही जगह | इंस्टॉल, एडमिन पैनल | ADR-0028 |
1. जब पहुँच जाँची न जा सके, तो मना कर दी जाती है¶
जहाँ कोई फ़ैसला पहुँच देता है, वहाँ गड़बड़ी होने पर सबसे सख़्त जवाब चुना जाता है। जिस प्रोफ़ाइल की अभिभावक सेटिंग्स पढ़ी न जा सकें, उसे कोई कंटेंट नहीं मिलता; जिस प्लगइन के कोड का विश्लेषण न हो सके, वह इंस्टॉल नहीं होता; रिमोट एक्सेस एक बार साफ़ चुनाव हो जाने के बाद उसी चुनाव पर चलता है, और जब वह सबको मना करता है, तो यह साफ़ चेतावनी देता है। रिमोट एक्सेस और साइन-इन अलग बातें हैं: पहला डिप्लॉयमेंट का चुनाव है, दूसरा वह है जो लाइब्रेरी की रक्षा करता है।
देखें उपयोगकर्ता, प्रोफ़ाइल और अभिभावक नियंत्रण, रिमोट एक्सेस और HTTPS, ADR-0026।
2. बाहरी कोड पर भरोसा नहीं किया जाता, उसे सीमित रखा जाता है¶
प्लगइन को वही अनुमतियाँ मिलती हैं जो उसका manifest बताता है, और कुछ नहीं। इंस्टॉल से पहले उसका विश्लेषण होता है, वह बिना सीधे नेटवर्क वाले सैंडबॉक्स में चलता है, और उसके पास एक token होता है जो डिफ़ॉल्ट रूप से मना होता है। सैंडबॉक्स अब भी क्या नहीं रोक सकता, यह इशारों में नहीं छोड़ा जाता, साफ़ लिखा जाता है।
देखें प्लगइन सैंडबॉक्स और ख़तरा मॉडल, ADR-0012, ADR-0014।
3. जब भी हो सके, असली फ़ाइल दी जाती है¶
सबसे पहली पसंद है फ़ाइल जैसी है वैसी, फिर वही ट्रैक किसी दूसरे container में, फिर सिर्फ़ उन ट्रैक का ट्रांसकोड जिन्हें इसकी ज़रूरत है। क्वालिटी कोई ऐसी चीज़ नहीं जो दर्शक को चलाने से पहले चुननी पड़े: सर्वर स्रोत की क्वालिटी बनाए रखता है, जब तक कोई असली रुकावट (डिवाइस, कनेक्शन, कोई सीमा) ऐसा करने से न रोके।
देखें Evey प्लेबैक का तरीका कैसे चुनता है।
4. फ़ैसले साबित हुई बातों पर टिके हैं, नामों पर नहीं¶
प्लेयर की क्षमताएँ उससे आती हैं जो उसका डिवाइस बताता है, जाने-पहचाने डिवाइस की किसी सूची से नहीं। ग्राफ़िक्स कार्ड उन कामों के लिए इस्तेमाल होता है जो उसने माप के दौरान पास किए, न कि उनके लिए जो उसके मॉडल को सपोर्ट करने चाहिए। जब कोई क्षमता साबित न हो सके, तो सर्वर सावधानी वाला जवाब चुनता है: अनजाने कास्ट receiver को सबसे पुराने receiver की क्षमताएँ मिलती हैं, और जिन pixel format को प्लेयर अभी नहीं बताते, वे एक तय compatibility नियम पर चलते हैं। ज़्यादा मान लेने से काली स्क्रीन या गलत रंग आते हैं; कम मान लेने से बस एक ट्रांसकोड ज़्यादा होता है।
देखें Chromecast पर कास्ट करना, हार्डवेयर एक्सेलेरेशन, ADR-0029।
5. एक प्लेबैक, एक फ़ैसला¶
प्लेबैक का फ़ैसला एक बार होता है, जब वह शुरू होता है, और सेशन का हर manifest और segment उसी फ़ैसले से दिया जाता है। प्लेयर को कभी दो अलग encoding के segment नहीं मिलते, और स्ट्रीम जानकारी जो बताती है, वह उसी भेजने की योजना (serving plan) से निकलता है जिसे प्लेबैक pipeline इस्तेमाल करती है; दोनों दिशाओं में टेस्ट इसकी जाँच करते हैं।
देखें प्लेबैक पाइपलाइन, ADR-0030, ADR-0024।
6. सर्वर खुद को मशीन के हिसाब से ढालता है¶
सर्वर मापता है कि वह कितना ट्रांसकोड कर सकता है, और उससे ज़्यादा स्वीकार नहीं करता: छोटी मशीन कम ट्रांसकोड वाली स्ट्रीम चलाती है, बजाय इसके कि सब बुरी तरह चलें। प्लेबैक सबसे पहले है; जब कोई देख रहा हो, तो बैकग्राउंड का काम रुक जाता है। वही इमेज एक NAS पर भी चलती है और कई ग्राफ़िक्स कार्ड वाले सर्वर पर भी।
देखें ट्रांसकोडिंग और सर्वर की क्षमता, बैकग्राउंड का काम और सर्वर पर लोड।
7. कम सेटिंग्स, हर एक एक ही जगह¶
जो सर्वर शुरू होने से पहले मौजूद होना चाहिए (स्टोरेज, secret, सार्वजनिक पता), वह compose फ़ाइल में है; जो कुछ बाद में बदल सकता है, वह एडमिन पैनल में है, डेटाबेस में सहेजा जाता है, और जहाँ किसी चीज़ को restart की ज़रूरत नहीं, वहाँ बिना restart के लागू होता है। जहाँ हो सके, पहचान और माप सेटिंग्स की जगह लेते हैं: एक इंस्टॉलेशन बस एक compose फ़ाइल, लाइब्रेरी और उपयोगकर्ता है।
देखें इंस्टॉल, कॉन्फ़िगरेशन रेफ़रेंस, ADR-0028।
फ़ैसलों के रिकॉर्ड¶
ढाँचे वाले फ़ैसले architecture decision record के रूप में दर्ज होते हैं, संदर्भ, तौले गए विकल्पों और नतीजों के साथ। ये कोड के साथ रखे जाते हैं: docs/adr।