Greasemonkey: Lassen Sie den Server ein Skript liefern, das nie (automatisch) aktualisiert wird

<strong i="5">@updateURL</strong> about:blank + <strong i="7">@downloadURL</strong> about:blank sollte es tun (zumindest war es in GM 3.x möglich, automatische Updates damit zu deaktivieren).

updateURL und downloadURL werden für 4.x nicht unterstützt.

In 3.x haben wir dafür nur die Standard-AOM-Steuerelemente verwendet.

In 4.x haben wir noch keine automatischen Updates, also müssen wir dies einfach als Basisfeature hinzufügen, sobald wir dies tun.

Würde das Setzen von <strong i="5">@downloadURL</strong> none mit dem übereinstimmen, was für 4.x geplant ist?

Oh, mir ist gerade aufgefallen, dass Sie sagen, dass der Server, der das Skript liefert, GM mitteilt, dass er das Skript nicht aktualisieren soll. (Ups, bin nicht ganz bis zum Ende der Beschreibung gekommen...)

Es ist nicht geplant, jemals den Wert einer @...URL Eigenschaft in GM 4 zu lesen/zu verwenden. Ich kann nichts versprechen, bis der Update-Code endlich geschrieben wird, aber eine Art HTTP-Header fühlt sich besser an, als zu versuchen, die Quelle zu ändern des Skripts.

OTOH Wenn TM den Wert none unterstützt, ist immer die Kompatibilität zu berücksichtigen.

Der OP sagt:

Die Installations-URL enthält einen Parameter, der die Version angibt.

Daher gehe ich davon aus, dass die Abfrageparameter effektiv Permalinks zu bestimmten Benutzerskripten sind. Es ist auch sehr wahrscheinlich, dass jede Auto-Update-/Check-for-Update-Funktionalität das intern gespeicherte downloadUrl (das nur die URL der Erstinstallation ist). Ich glaube, dass wir diese Form des Permalinking mit sehr minimalen Änderungen unterstützen können, indem wir beim Erkennen von Benutzerskripts den Abfrageparameterabgleich hinzufügen. Wird durch Hinzufügen von *://*/*.user.js?* zum user-script-detect.run.js Listener ausgeführt.

Oh, mir ist gerade aufgefallen, dass Sie sagen, dass der Server, der das Skript liefert, GM mitteilt, dass er das Skript nicht aktualisieren soll.

Ja genau.

Eine Art HTTP-Header fühlt sich besser an, als zu versuchen, die Quelle des Skripts zu ändern

Greasy Fork speichert die Skripte in der DB und schreibt die Quelle trotzdem neu (zB generiert eine meta.js aus einer user.js). Ein Wechsel der Quelle ist für mich kein Problem. HTTP-Header können ein Problem darstellen, da die Skripte möglicherweise Caching-Software durchlaufen.

Daher gehe ich davon aus, dass die Abfrageparameter effektiv Permalinks zu bestimmten Benutzerskripten sind.

In meinem Sprachgebrauch stellt der Versionsparameter einen Permalink zu einer bestimmten Version eines bestimmten Benutzerskripts bereit.

Ich glaube, wir können diese Form des Permalinkings unterstützen, indem wir beim Erkennen von Benutzerskripten den Abfrageparameterabgleich hinzufügen.

Greasy Fork verwendet URL-Parameter zu keinem anderen Zweck als zum Verlinken auf bestimmte Versionen, aber ich kann nicht versprechen, dass dies in Zukunft nicht der Fall sein wird, oder dass andere Sites dies auch nicht tun.

Bei weiterer Überlegung: Es würde mehr Aufwand erfordern , Engine- @derjanb , @gera2ld), aber: Wenn wir die Überprüfung der Quellcodeverwaltung

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

Lassen Sie das Skript angeben, wie oft es automatisch aktualisiert werden soll. Wenn ich in der aktiven Entwicklung bin, kann ich es niedrig halten, wenn ich stabil werde, kann ich es optimieren (aber wieder runter, wenn/wenn ich wieder mit dem Update beginne). Und ein Skripthost kann (wenn er das Skript sowieso munget) den Wert nach Belieben überschreiben (basierend auf Dingen wie der Anzahl der Benutzer, die es installiert haben, Serverressourcen usw.).

Ich hätte gerne einen aussagekräftigeren Namen, habe aber noch keinen bestimmten Kandidaten, der mir gefällt.

* Obwohl für den Wert "nie" auch <strong i="14">@downloadURL</strong> none Unterstützung hinzugefügt werden kann.

Aus technischer Sicht sollte es etw. sein. wie @updatefrequency (zu lang?) oder @updatecycle .
Und hoffentlich gibt es einen Trigger, um eine Überprüfung aller Skripte manuell zu starten...

Lassen Sie das Skript angeben, wie oft es automatisch aktualisiert werden soll. Wenn ich in der aktiven Entwicklung bin, kann ich es niedrig halten, wenn ich stabil werde, kann ich es optimieren (aber wieder runter, wenn/wenn ich wieder mit dem Update beginne). Und ein Skripthost kann (wenn er das Skript sowieso munget) den Wert nach Belieben überschreiben (basierend auf Dingen wie der Anzahl der Benutzer, die es installiert haben, Serverressourcen usw.).

Klingt vernünftig.

Ich hätte gerne einen aussagekräftigeren Namen, habe aber noch keinen bestimmten Kandidaten, der mir gefällt.

Vielleicht @updateInterval ?

oder einfach @updatetime ... (nicht ganz genau, aber eingängig)

@updatetime denke ich eher an "um 8:00 Uhr" als an eine Frequenz.

@Sxderp Sie würden also <strong i="6">@updatefreq</strong> 1d ?

Ich bin kein Muttersprachler, aber der Wert (zB 24h) ist nicht wirklich eine Frequenz. Es ist ein Intervall oder eine Periode, oder? 🤓

<strong i="5">@updateinterval</strong> 1day hört sich gut an. Ich würde von "Punkt" abraten, da es im allgemeinen Englisch eine überladene Bedeutung hat (obwohl es eine genaue wissenschaftliche Bedeutung hat).

@updateinterval ist so ungenau wie @updatetime . Sie interessieren sich nicht für das Intervall, sondern für die (maximale) Zeitspanne zwischen Updates...

Ich mag Zeitraffer nicht wirklich, daher wäre mein nächster Vorschlag <strong i="5">@updatespan</strong> 1d ...

@arantius , wann wird ein automatisches Update geplant? Ich kann in FF60 nicht auf 3.x umstellen.