Greasemonkey: Разрешить серверу доставить скрипт, который никогда не будет (автоматически) обновляться

<strong i="5">@updateURL</strong> about:blank + <strong i="7">@downloadURL</strong> about:blank должен сделать это (по крайней мере, можно было отключить автоматические обновления, используя это в GM 3.x).

updateURL и downloadURL не поддерживаются для 4.x.

В 3.x мы просто использовали для этого стандартные элементы управления AOM.

В 4.x у нас еще нет автоматических обновлений, поэтому нам просто нужно будет включить это как базовую функцию, как только мы это сделаем.

Согласуется ли установка <strong i="5">@downloadURL</strong> none с тем, что запланировано для 4.x?

О, я только что понял, что вы хотите, чтобы сервер, доставляющий скрипт, сказал GM, что он не должен обновлять скрипт. (Упс, не совсем дошел до конца описания ...)

Нет никаких планов когда-либо читать / использовать значение какого-либо свойства @...URL в GM 4. Я не могу ничего обещать, пока, наконец, не будет написан код обновления, но какой-то HTTP-заголовок выглядит лучше, чем пытаться изменить источник сценария.

OTOH, если TM не поддерживает значение none, всегда следует учитывать совместимость.

ОП говорит:

URL-адрес установки включает параметр, указывающий в версии.

Исходя из этого, я предполагаю, что параметры запроса фактически являются постоянными ссылками на определенные пользовательские сценарии. Также наиболее вероятно, что любая функция автоматического обновления / проверки наличия обновлений будет использовать внутренне сохраненный downloadUrl (который является просто URL-адресом начальной установки). Я считаю, что с минимальными изменениями мы можем поддержать эту форму постоянной ссылки, добавив сопоставление параметров запроса при обнаружении пользовательских скриптов. Выполняется добавлением *://*/*.user.js?* к слушателю user-script-detect.run.js .

О, я только что понял, что вы хотите, чтобы сервер, доставляющий скрипт, сказал GM, что он не должен обновлять скрипт.

Да, точно.

какой-то HTTP-заголовок кажется лучше, чем пытаться изменить источник скрипта

Greasy Fork сохраняет скрипты в БД и в любом случае переписывает исходный код (например, генерирует meta.js из user.js). Смена источника для меня не проблема. Заголовки HTTP могут быть проблемой, поскольку сценарии могут проходить через программное обеспечение кэширования.

Исходя из этого, я предполагаю, что параметры запроса фактически являются постоянными ссылками на определенные пользовательские сценарии.

На моем языке параметр версии предоставляет постоянную ссылку на конкретную версию определенного пользовательского скрипта.

Я считаю, что мы можем поддержать эту форму постоянной ссылки, добавив сопоставление параметров запроса при обнаружении пользовательских скриптов.

Greasy Fork не использует параметры URL-адреса для каких-либо других целей, кроме ссылки на определенные версии, но я не могу обещать, что этого не будет в будущем, или что другие сайты тоже.

После дальнейшего размышления: потребовалось бы больше усилий, чтобы быть совместимым с кросс-движком ( @derjanb , @ gera2ld), но: Если мы собираемся позволить проверять обновления системы управления версиями, я думаю больше о строках новой записи * Такие как:

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

Пусть сценарий указывает, как часто он должен обновляться автоматически. Когда я нахожусь в активной разработке, я могу держать его на низком уровне, когда я становлюсь стабильным, я могу его настроить (но отступить, если / когда я снова начну обновление). И хост сценария может (если он все равно будет изменять сценарий) перезаписать значение по своему усмотрению (на основе таких вещей, как количество пользователей, которые установили его, ресурсы сервера и т. Д.).

Я бы хотел более информативное имя, но пока у меня нет конкретного кандидата, который мне нравится.

* Хотя для значения never можно добавить поддержку <strong i="14">@downloadURL</strong> none .

С технической точки зрения это должно быть что-то особенное. например @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 , когда будет запланировано автоматическое обновление? Не могу перейти на 3.х в FF60.