Ответ 1
Использование этих ключей обескураживается главным образом ведущим разработчиком Greasemonkey. Большинство других, в том числе команда Tampermonkey не нуждаются в таком предупреждении.
Также обратите внимание, что эти директивы всегда не всегда необходимы для автоматического обновления.
Некоторые причины, по которым он сказал бы, что это необычно, и что "большинство" сценариев должны его пропускать:
- В большинстве случаев это не нужно, см., как работают обновления и как эти директивы работают ниже.
- Добавление и использование этих директив - это всего лишь несколько элементов, которые должен проверить и поддерживать писатель script. Зачем делать работу, если она не нужна?
- Реализация обновления и эти директивы были ошибочными и, возможно, не очень хорошо реализованы в Greasemonkey.
- Tampermonkey и другие двигатели, внедряют обновления и эти директивы несколько иначе. Это означает, что код, который работает на Tampermonkey, может не работать на Greasemonkey.
Обратите внимание, что эта запись wiki была сделана ведущим разработчиком Greasemonkey (Arantius); поэтому это был не просто шум вики.
Как работают обновления:
Script обновления проводятся в 4 этапа:
- Факсимильные и/или принудительные обновления включены.
- проверить.
- Фаза скачать.
- проанализировать и установить фазу.
По этому вопросу нас интересуют только этапы проверки и загрузки. Мы оговариваем, что обновления включены и что обновленный script был корректным и установлен правильно.
При обновлении скриптов Greasemonkey (и Tampermonkey) загружает файлы дважды:
- Первая загрузка, контролируемая значением script
updateURL
, предназначена только для проверки файла@version
(если есть) и даты - чтобы узнать, доступно ли обновление. -
Вторая загрузка, контролируемая значением script
downloadURL
, является фактической загрузкой нового script для установки. Эта загрузка будет возникать только в том случае, если файл сервера имеет более высокий@version
номер, чем локальный файл, и/или если файл сервера имеет более позднюю дату, чем локальный файл. (Остерегайтесь того, что существуют критические различия между двигателями script.)См. "Почему вы можете использовать @downloadURL и @updateURL" ниже, для причин использования 2 файлов.
Работа @downloadURL
и @updateURL
:
@downloadURL
просто переопределяет внутреннее местоположение "URL загрузки" по умолчанию. @updateURL
просто переопределяет внутренний "URL-адрес обновления" (или проверьте).
В большинстве случаев нет необходимости делать это. См. Ниже.
- Когда вы устанавливаете учетную запись, Greasemonkey автоматически записывает местоположение установки. Мета-директива не требуется. По умолчанию это означает, что Greasemonkey будет проверять наличие обновлений и загружать любые обновления.
- Но если указано
@downloadURL
, Greasemonkey будет и проверять и загружать из указанного места, а не в сохраненное местоположение. - Но если задано
@updateURL
, Greasemonkey проверит (не загружается) из указанного местоположения "update".
Итак: @updateURL
переопределяет как @downloadURL
, так и местоположение по умолчанию для проверки только операций.
Хотя: @downloadURL
переопределяет местоположение по умолчанию для проверки и загрузки (если не присутствует @updateURL
).
Почему вы можете использовать @downloadURL
и @updateURL
:
Во-первых, есть 2 загрузки и потенциально 2 разных местоположения в основном по причинам скорости и пропускной способности. Рассмотрим сценарий, в котором очень большой пользовательский учет имеет тысячи пользователей:
- Браузеры этих пользователей будут постоянно мешать проверке хост-сервера, чтобы узнать, доступно ли обновление. В большинстве случаев этого не было бы, и большой файл будет загружаться снова и снова неоправданно.
Это стало проблемой для таких сайтов, как теперь несуществующий
userscripts.org
. - Таким образом, была разработана система, в которой был создан отдельный файл, чтобы просто хранить информацию о версии (и дате). Таким образом, сервер теперь имеет
veryLarge.user.js
иveryLarge.meta.js
-
veryLarge.meta.js
будет обновляться (разработчиком) каждый раз, когда будет использоваться usercript, и будет содержать Блок метаданных отveryLarge.user.js
. - Таким образом, тысячи браузеров будут просто повторно загружать гораздо меньше
veryLarge.meta.js
- экономя все время и сохраняя пропускную способность сервера.
В настоящее время оба Greasemonkey и Tampermonkey автоматически ищут файл *.meta.js
, поэтому обычно нет необходимости указывать его отдельно.
Итак, зачем явно указывать @downloadURL
и/или @updateURL
?. Возможные причины:
- Ваш script может быть установлен несколькими способами или из нескольких источников (вырезать и вставить, локально скопированный файл, вторичный сервер и т.д.), и вы хотите сохранить только одну "главную" версию.
- Вы хотите отслеживать, сколько начальных и/или обновлений загружено script.
-
@downloadURL
- также удобный "самодополнительный" способ записи/передачи, где пользователь получил script. - По какой-то причине вам нужен файл
*.meta.js
на другом сервере, чем по имени пользователя. - Возможно, проблема http против https (нужно что-то в этом разобраться).
- Вы плохой человек, и вы хотите, чтобы script обновлял вредоносную версию в какой-то будущей дате с сервера, который вы контролируете, - это не тот, где был установлен script.
Некоторые различия между Greasemonkey и Tampermonkey:
(Предупреждение: я все еще не проверял все это время. Возможно, будет изменено, если Tampermonkey постоянно улучшается (и Greasemonkey тоже сильно меняется).
-
Tampermonkey требует директивы
@version
как для текущего, так и для нового файла. Вот как Tampermonkey определяет, доступно ли обновление.Greasemonkey также будет использовать этот метод, поэтому всегда включает
@version
в сценарии, которые вы, возможно, захотите автоматически обновить.Однако Greasemonkey также требует, чтобы файл обновления был более новым. И если никакой версии нет, Greasemonkey просто сравнит только даты. Обратите внимание, что это вызвало проблемы в Greasemonkey в прошлом, а также по-глупо предполагает, что многие разные машины точно синхронизируются с правильной датой и временем.
-
Greasemonkey будет обновлять только по
https://
схемам по умолчанию, но при необходимости может быть установлен для разрешения схемhttp://
иftp://
. -
Оба механизма никогда не разрешают обновления из
file://
схем.