Greasemonkey: सर्वर को एक स्क्रिप्ट डिलीवर करने दें जो कभी भी (ऑटो) अपडेट नहीं होगी

<strong i="5">@updateURL</strong> about:blank + <strong i="7">@downloadURL</strong> about:blank इसे करना चाहिए (कम से कम जीएम 3.x में इसका उपयोग करके ऑटो अपडेट को निष्क्रिय करना संभव था)।

updateURL और downloadURL 4.x के लिए समर्थित नहीं हैं।

3.x में हमने इसके लिए मानक AOM नियंत्रणों का उपयोग किया है।

4.x में हमारे पास अभी तक स्वचालित अपडेट नहीं हैं, इसलिए हमें इसे एक बार करने के बाद बस इसे एक आधार सुविधा के रूप में शामिल करना होगा।

क्या <strong i="5">@downloadURL</strong> none को 4.x के लिए नियोजित योजना के साथ संरेखित करना होगा?

ओह, मुझे अभी एहसास हुआ है कि आप कह रहे हैं कि आप उस सर्वर को चाहते हैं जो स्क्रिप्ट को जीएम को बताए कि उसे स्क्रिप्ट को अपडेट नहीं करना चाहिए। (ओह, विवरण के अंत तक नहीं पहुंचा ...)

जीएम 4 में किसी भी @...URL संपत्ति के मूल्य को कभी भी पढ़ने/उपयोग करने की कोई योजना नहीं है। मैं कुछ भी वादा नहीं कर सकता जब तक कि अद्यतन कोड अंततः लिखा नहीं जाता है, लेकिन किसी प्रकार का HTTP शीर्षलेख स्रोत को बदलने की कोशिश करने से बेहतर लगता है। स्क्रिप्ट का।

ओटीओएच अगर टीएम किसी भी मूल्य का समर्थन नहीं करता है, तो विचार करने के लिए हमेशा अनुकूलता होती है।

ओपी कहते हैं:

इंस्टॉल यूआरएल में संस्करण में दर्शाने वाला एक पैरामीटर शामिल है।

इससे, मुझे लगता है कि क्वेरी पैरामीटर विशिष्ट उपयोगकर्ता स्क्रिप्ट के लिए प्रभावी रूप से स्थायी लिंक हैं। यह भी सबसे अधिक संभावना है कि कोई भी स्वत: अद्यतन/अपडेट के लिए जांच कार्यक्षमता आंतरिक रूप से सहेजे गए downloadUrl (जो केवल प्रारंभिक स्थापना का URL है) का उपयोग करेगी। बहुत कम बदलाव के साथ, मेरा मानना ​​है कि हम उपयोगकर्ता स्क्रिप्ट का पता लगाते समय क्वेरी पैरामीटर मिलान को जोड़कर स्थायी लिंकिंग के इस रूप का समर्थन कर सकते हैं। *://*/*.user.js?* को user-script-detect.run.js श्रोता में जोड़कर पूरा किया गया।

ओह, मुझे अभी एहसास हुआ है कि आप कह रहे हैं कि आप उस सर्वर को चाहते हैं जो स्क्रिप्ट को जीएम को बताए कि उसे स्क्रिप्ट को अपडेट नहीं करना चाहिए।

हाँ बिल्कुल।

किसी प्रकार का HTTP शीर्षलेख स्क्रिप्ट के स्रोत को बदलने की कोशिश करने से बेहतर लगता है

ग्रीसी फोर्क स्क्रिप्ट को डीबी में संग्रहीत करता है और वैसे भी स्रोत को फिर से लिखता है (उदाहरण के लिए उपयोगकर्ता से मेटा.जेएस उत्पन्न करता है। जेएस)। स्रोत बदलना मेरे लिए कोई समस्या नहीं है। HTTP हेडर एक समस्या हो सकती है क्योंकि स्क्रिप्ट कैशिंग सॉफ़्टवेयर के माध्यम से हो सकती है।

इससे, मुझे लगता है कि क्वेरी पैरामीटर विशिष्ट उपयोगकर्ता स्क्रिप्ट के लिए प्रभावी रूप से स्थायी लिंक हैं।

मेरी भाषा में, संस्करण पैरामीटर एक विशिष्ट उपयोगकर्ता स्क्रिप्ट के विशिष्ट संस्करण के लिए एक स्थायी लिंक प्रदान करता है।

मेरा मानना ​​है कि हम उपयोगकर्ता स्क्रिप्ट का पता लगाते समय क्वेरी पैरामीटर मिलान को जोड़कर स्थायी लिंकिंग के इस रूप का समर्थन कर सकते हैं।

ग्रीसी फोर्क विशिष्ट संस्करणों से लिंक करने के अलावा किसी अन्य उद्देश्य के लिए यूआरएल पैरामीटर का उपयोग नहीं करता है, लेकिन मैं वादा नहीं कर सकता कि यह भविष्य में नहीं होगा, या अन्य साइटें या तो नहीं।

आगे के प्रतिबिंब पर: क्रॉस-इंजन के अनुरूप होने के लिए और अधिक प्रयास करना होगा ( @derjanb , @gera2ld), लेकिन: अगर हम स्रोत नियंत्रण अद्यतन की जांच करने जा रहे हैं तो मैं एक नई प्रविष्टि की तर्ज पर और सोच रहा हूं * जैसे कि:

// <strong i="7">@updates</strong> never
// <strong i="8">@updates</strong> 24h
// <strong i="9">@updates</strong> 7d

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

मुझे एक और वर्णनात्मक नाम चाहिए, लेकिन अभी तक मुझे पसंद करने वाला कोई विशिष्ट उम्मीदवार नहीं है।

* हालांकि कभी भी मूल्य के लिए, <strong i="14">@downloadURL</strong> none समर्थन भी जोड़ा जा सकता है।

तकनीकी पहलू से, यह sth होना चाहिए। जैसे @updatefrequency (बहुत लंबा?) या @updatecycle ।
और उम्मीद है, मैन्युअल रूप से सभी स्क्रिप्ट की जांच शुरू करने के लिए एक ट्रिगर होगा ...

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

उचित लगता है।

मुझे एक और वर्णनात्मक नाम चाहिए, लेकिन अभी तक मुझे पसंद करने वाला कोई विशिष्ट उम्मीदवार नहीं है।

शायद @updateInterval ?

या बस @updatetime ... (बहुत सटीक नहीं, लेकिन आकर्षक)

@updatetime मुझे आवृत्ति के बजाय "सुबह 8:00 बजे" के बारे में सोचने पर मजबूर करता है।

@Sxderp तो आप <strong i="6">@updatefreq</strong> 1d समर्थन करेंगे?

मैं एक देशी वक्ता नहीं हूं, लेकिन मान (अर्थात 24 घंटे) वास्तव में एक आवृत्ति नहीं है। यह एक अंतराल या अवधि है, है ना? मैं

<strong i="5">@updateinterval</strong> 1day अच्छा लगता है। मैं "अवधि" के खिलाफ अनुशंसा करता हूं क्योंकि इसका सामान्य अंग्रेजी में अतिभारित अर्थ है (भले ही इसका सटीक वैज्ञानिक अर्थ हो)

@updateinterval @updatetime जितना सटीक नहीं है। आप अंतराल में रुचि नहीं रखते हैं, लेकिन अपडेट के बीच (अधिकतम) समय अवधि ...

मुझे वास्तव में चूक पसंद नहीं है, इसलिए मेरा अगला सुझाव होगा <strong i="5">@updatespan</strong> 1d ...

@arantius , स्वचालित अपडेट कब शेड्यूल किया जाएगा? मैं FF60 में 3.x पर स्विच नहीं कर सकता।