Lorawan-stack: वेबहुक URL में कस्टम चर समर्थन

फ़ील्ड कैसे दिखते हैं, इसके आधार पर, मुझे संदेह है कि आप इसे text/template के साथ लागू करने की योजना बना रहे थे। यदि वास्तव में ऐसा है, तो कृपया इस तथ्य से अवगत रहें कि प्रत्येक अपलिंक पर टेम्पलेट्स को पार्स करना और निष्पादित करना (विशेषकर यदि यह केवल आधार URL ही नहीं बल्कि पथ भी है) संभावित रूप से काफी संसाधन गहन हो सकता है।
साथ ही, एक बहुत ही सीमित संरचना का उपयोग करना सुनिश्चित करें जिसके साथ टेम्पलेट निष्पादित किया जाएगा। केवल आदिम प्रकारों का उपयोग करें (इसलिए सभी EUI/DevAddr को स्ट्रिंग्स में बदलें), पॉइंटर्स से बचें।

मुझे लगता है कि हम टेम्पलेट को हर बार फिर से संकलित करने से बचने के लिए वेबहुक आईडी + updated_at का उपयोग करके स्वयं टेम्पलेट को कैश कर सकते हैं। साथ ही यह वास्तव में मामला है कि केवल स्ट्रिंग्स को टेम्पलेट में ही पास किया जाना चाहिए (और मैं पसंद करूंगा कि हम पहचानकर्ताओं के बाहर किसी और चीज का उपयोग न करें)।

मुझे लगता है कि दो विकल्प हैं;

• इस उपयोग के मामले के लिए विशिष्ट एक बहुत ही सरल संरचना के साथ text/template का उपयोग करें। यानी, *ttnpb.ApplicationUp पास न करें लेकिन WebhookTemplateFields केवल उस सामान के साथ जो हम समर्थन करते हैं
• ज्ञात फ़ील्ड पर स्ट्रिंग प्रतिस्थापन का उपयोग करें। सुपर फास्ट, वही परिणाम

यदि हम दूसरे के लिए जाते हैं, तो हमें शायद गो टेम्प्लेट सिंटैक्स का उपयोग बिल्कुल भी नहीं करना चाहिए, क्योंकि यह सिर्फ लोगों को भ्रमित करेगा (क्यों डॉट? क्या यह रिक्त स्थान के साथ गद्देदार है?)

यदि हम सत्यापन नियमों को समान रखना चाहते हैं, तो हम $app_id जैसे प्लेसहोल्डर का उपयोग करने पर विचार कर सकते हैं। इस तरह प्लेसहोल्डर होस्ट में मान्य नहीं होंगे (क्योंकि हम ऐसा नहीं चाहते हैं), लेकिन वे पथ में मान्य होंगे (मुझे लगता है कि URL पथों में $ की अनुमति है, हमें इसे जांचने की आवश्यकता है )

$ RFC3986 सेक्शन 2.2 के अनुसार होस्ट और पथ दोनों के हिस्से के रूप में मान्य है। ऐसा कहने के साथ, हमें url.URL के मेजबान भाग को पार्स करने के लिए मजबूर नहीं किया जाता है।

URI टेम्प्लेट के लिए मानक ( RFC 6570 के अनुसार, 1.2 और 2.2 देखें) सिंटैक्स {[operator]variable-list} है। चूंकि हम एक हॉट स्पॉट में काम कर रहे हैं, मुझे विश्वास है कि ऑपरेटरों को छोड़ने का यह एक अच्छा औचित्य है (क्योंकि उन्हें विस्तारित प्रसंस्करण की आवश्यकता होगी), और केवल एक चर की अनुमति दें। यह हमें पहिया को फिर से खोजे बिना string.ReplaceAll का उपयोग करने की अनुमति देता है।

"एक चर की अनुमति दें" से आपका क्या मतलब है?

मुझे यह भी लगता है कि उपयोगकर्ता अनुभव-वार, प्रदर्शन हिट के अलावा text/template का उपयोग नहीं करना अच्छा है। मैं PHP-शैली परिवर्तनीय नामों के साथ ठीक हूं।

ऊपर उल्लिखित मानक {appEUI,devEUI} जैसे अभिव्यक्तियों की अनुमति देगा, जो हमें सरल स्ट्रिंग प्रतिस्थापन का उपयोग करने की अनुमति नहीं देगा। ध्यान दें कि मैंने {appEUI}/{devEUI} जैसे अभिव्यक्तियों को अस्वीकार नहीं किया है, जिनमें प्रति कैप्चर केवल एक चर है, और पूरी तरह से ठीक हैं।

यह कैसे है?

वह एक आंतरिक पैकेज है और इसे मुख्य पैकेज के बाहर आयात नहीं किया जा सकता है, लेकिन इसे ऐसा करना चाहिए।
संपादित करें: मुख्य पैकेज फ़ंक्शन को भी उजागर करता है।