Greasemonkey: Laisser le serveur livrer un script qui ne sera jamais (auto) mis à jour

<strong i="5">@updateURL</strong> about:blank + <strong i="7">@downloadURL</strong> about:blank devrait le faire (au moins, il était possible de désactiver les mises à jour automatiques en utilisant cela dans GM 3.x).

updateURL et downloadURL ne sont pas pris en charge pour 4.x.

Dans 3.x, nous avons juste utilisé les commandes AOM standard pour cela.

Dans 4.x, nous n'avons pas encore de mises à jour automatiques, nous devrons donc simplement l'inclure comme fonctionnalité de base, une fois que nous le ferons.

Est-ce que mettre <strong i="5">@downloadURL</strong> none s'alignerait sur ce qui est prévu pour 4.x ?

Oh, je viens juste de réaliser que vous dites que vous voulez que le serveur qui livre le script dise au GM qu'il ne doit pas mettre à jour le script. (Oups, je n'ai pas tout à fait atteint la fin de la description ...)

Il n'est pas prévu de lire/utiliser la valeur d'une propriété @...URL dans GM 4. Je ne peux rien promettre jusqu'à ce que le code de mise à jour soit enfin écrit, mais une sorte d'en-tête HTTP est mieux que d'essayer de changer la source du scénario.

OTOH si TM prend en charge une valeur none, il y a toujours une compatibilité à considérer.

L'OP dit :

L'URL d'installation comprend un paramètre indiquant dans la version.

À partir de là, je suppose que les paramètres de requête sont effectivement des liens permanents vers des scripts utilisateur spécifiques. Il est également très probable que toute fonctionnalité de mise à jour automatique/vérification de mise à jour utilise le downloadUrl enregistré en interne (qui n'est que l'URL de l'installation initiale). Avec un changement très minime, je pense que nous pouvons prendre en charge cette forme de liaison permanente en ajoutant la correspondance des paramètres de requête lors de la détection des scripts utilisateur. Obtenu en ajoutant *://*/*.user.js?* à l'écouteur user-script-detect.run.js .

Oh, je viens juste de réaliser que vous dites que vous voulez que le serveur qui livre le script dise au GM qu'il ne doit pas mettre à jour le script.

Oui, exactement.

une sorte d'en-tête HTTP se sent mieux que d'essayer de changer la source du script

Greasy Fork stocke les scripts dans la base de données et réécrit quand même la source (par exemple, génère un meta.js à partir d'un user.js). Changer la source n'est pas un problème pour moi. Les en-têtes HTTP peuvent être un problème car les scripts peuvent passer par un logiciel de mise en cache.

À partir de là, je suppose que les paramètres de requête sont effectivement des liens permanents vers des scripts utilisateur spécifiques.

Dans mon jargon, le paramètre de version fournit un lien permanent vers une version spécifique d'un script utilisateur spécifique.

Je pense que nous pouvons prendre en charge cette forme de liaison permanente en ajoutant la correspondance des paramètres de requête lors de la détection des scripts utilisateur.

Greasy Fork n'utilise pas de paramètres d'URL à d'autres fins que de créer des liens vers des versions spécifiques, mais je ne peux pas promettre que ce ne sera pas le cas à l'avenir, ou que d'autres sites ne le feront pas non plus.

Après réflexion : il faudrait plus d'efforts pour être compatible avec tous les moteurs ( @derjanb , @gera2ld), mais : si nous laissons le contrôle de source vérifier la mise à jour, je pense plutôt à une nouvelle entrée * tel que:

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

Laissez le script spécifier la fréquence à laquelle il doit être mis à jour automatiquement. Quand je suis en développement actif, je peux le garder bas, quand je deviens stable, je peux l'ajuster (mais reculer si/quand je recommence la mise à jour). Et un hôte de script peut (s'il veut quand même modifier le script) écraser la valeur comme bon lui semble (en fonction de facteurs tels que le nombre d'utilisateurs qui l'ont installé, les ressources du serveur, etc.).

J'aimerais un nom plus descriptif mais je n'ai pas encore de candidat spécifique que j'aime.

* Bien que pour la valeur jamais, le support <strong i="14">@downloadURL</strong> none peut également être ajouté.

D'un point de vue technique, ça devrait être qch. comme @updatefrequency (trop long ?) ou @updatecycle .
Et j'espère qu'il y aura un déclencheur pour lancer une vérification manuelle de tous les scripts...

Laissez le script spécifier la fréquence à laquelle il doit être mis à jour automatiquement. Quand je suis en développement actif, je peux le garder bas, quand je deviens stable, je peux l'ajuster (mais reculer si/quand je recommence la mise à jour). Et un hôte de script peut (s'il veut quand même modifier le script) écraser la valeur comme bon lui semble (en fonction de facteurs tels que le nombre d'utilisateurs qui l'ont installé, les ressources du serveur, etc.).

Semble raisonnable.

J'aimerais un nom plus descriptif mais je n'ai pas encore de candidat spécifique que j'aime.

Peut-être @updateInterval ?

ou simplement @updatetime ... (pas très exact, mais accrocheur)

@updatetime me fait penser à "à 8h00" plutôt qu'à une fréquence.

@Sxderp Donc, vous soutiendriez <strong i="6">@updatefreq</strong> 1d ?

Je ne suis pas un locuteur natif, mais la valeur (c'est-à-dire 24h) n'est pas vraiment une fréquence. C'est un intervalle ou une période, non ? ??

<strong i="5">@updateinterval</strong> 1day sonne bien. Je déconseillerais "période" car il a un sens surchargé en anglais courant (même s'il a un sens scientifique précis)

@updateinterval est aussi imprécis que @updatetime . Vous n'êtes pas intéressé par l'intervalle, mais le laps de temps (maximum) entre les mises à jour...

Je n'aime pas trop le lapsus, donc ma prochaine suggestion serait donc <strong i="5">@updatespan</strong> 1d ...

@arantius , quand la mise à jour automatique sera-t-elle programmée ? Je ne peux pas passer à 3.x dans FF60.