web-dev-qa-db-ja.com

downloadURLキーとupdateURLキーの使用が通常とは異なり、どのように機能するのですか？

私は GMのwiki を読んでいて、@downloadURL＆@updateURL（私はしませんでした）。しかし、どちらも助言されていないことでさらに混乱しました：

この値を指定することはまれです。ほとんどのスクリプトでは省略してください。

スクリプトが自動更新する唯一の方法であり、これらのキーを使用しない理由がわからないので、私はそれに驚いています。

ウィキ自体はかなり不足しており、他のフォーラムのソースは勧められないので、私はここで尋ねなければなりません。また、これらのキーについてのより詳細な情報をいただければ幸いです。

greasemonkeyuserscriptstampermonkey
31
ZeroUnderscoreOu

これらのキーの使用は、主にGreasemonkeyのリード開発者によって推奨されていません。 Tampermonkeyチーム を含む他のほとんどの人は、そのような警告の必要はないと感じています。
また、これらのディレクティブはnotであり、自動更新が機能するために常に必要であることに注意してください。

それが異常であり、「ほとんどの」スクリプトがそれを省略すべきであると彼が言う理由のいくつか：

  1. ほとんどの場合、それは必要ありません。以下の更新の仕組みとそれらのディレクティブの仕組みを参照してください。
  2. これらのディレクティブを追加して使用することは、スクリプトの作成者がチェックして維持する必要がある項目のほんの一部です。必要がないのになぜ仕事をするのか？.
  3. 更新の実装とそれらのディレクティブ はバグが多い であり、おそらく、Greasemonkeyでは十分に実装されていません。
  4. Tampermonkeyおよびその他のエンジンは、更新とそれらのディレクティブをわずかに異なる方法で実装します。これは、Tampermonkeyで動作するコードがGreasemonkeyで失敗する可能性があることを意味します。

Wikiエントリは Greasemonkeyのリード開発者（Arantius）自身が作成したものであることに注意してください ;ですから、wikiノイズだけではありませんでした。

更新の仕組み：

スクリプトの更新は4つのフェーズで行われます。

  1. enabled フェーズおよび/または「強制」更新。
  2. check フェーズ。
  3. download フェーズ。
  4. parse およびインストールフェーズ。

この質問では、checkとdownloadフェーズのみに関係しています。更新が有効であり、更新されたスクリプトが有効であり、正しくインストールされていることを規定しています。

スクリプトを更新するとき、Greasemonkey（およびTampermonkey）ファイルを2回ダウンロード：

  1. スクリプトのupdateURL値によって制御される最初のダウンロードは、ファイルの@version（存在する場合）と日付をチェックして、更新が利用可能かどうかを確認するだけです。

  2. 2番目のダウンロードは、スクリプトのdownloadURL値によって制御され、インストールする新しいスクリプトの実際のダウンロードです。このダウンロードは、サーバーファイルのローカルファイルよりも@version番号が大きい場合、またはサーバーファイルの日付がローカルファイルより新しい場合にのみ発生します。 （ここでは、スクリプトエンジン間に重要な違いがあることに注意してください。）

    2つのファイルのダウンロードが使用される理由については、下記の「@downloadURLと@updateURLを使用する理由」をご覧ください。


@downloadURLと@updateURLの仕組み：

@downloadURLは、デフォルトの内部「ダウンロードURL」の場所を上書きするだけです。
@updateURLは、デフォルトの内部「更新URL」（またはチェック）の場所をオーバーライドするだけです。
ほとんどの場合、これを行う必要はありません。下記参照。

  1. ユーザースクリプトをインストールすると、 Greasemonkeyがインストール場所を自動的に記録します。メタディレクティブは不要です。デフォルトでは、Greasemonkeyは更新のチェックと更新のダウンロードの両方を行います。
  2. ただし、@downloadURLが指定されている場合、Greasemonkeyはbothをチェックして、保存されている場所ではなく、指定された場所からダウンロードします。
  3. ただし、@updateURLが指定されている場合、Greasemonkeyは指定された「更新」場所から（ダウンロードではなく）チェックします。

つまり、@updateURLは、@downloadURLとchecking操作のみのデフォルトの場所の両方をオーバーライドします。
While：@downloadURLは、checkingとdownloadingの両方のデフォルトの場所を上書きします（@updateURLが存在します）。


@downloadURLおよび@updateURLを使用する理由：

まず、 2つのダウンロードがあり、速度と帯域幅の理由で主に 2つの異なる場所がある可能性があります。非常に大きなユーザースクリプトに数千人のユーザーがいるシナリオを考えてみましょう。

  • これらのユーザーのブラウザーは、更新が利用可能であるかどうかを確認するためにホストサーバーのチェックを常に叩いていました。ほとんどの場合、そうではなく、大きなファイルが不必要に何度もダウンロードされます。これは、現在は機能しなくなったuserscripts.orgなどのサイトで問題になるはずです。
  • したがって、バージョン（および日付）情報のみを保持するために別のファイルが作成されるシステムが開発されました。したがって、サーバーにはveryLarge.user.jsとveryLarge.meta.js
  • veryLarge.meta.jsは、ユーザースクリプトが更新されるたびに（開発者によって）更新され、 メタデータブロックveryLarge.user.jsのみが含まれます。
  • したがって、何千ものブラウザがはるかに小さいveryLarge.meta.jsを繰り返しダウンロードするだけで、誰もが時間を節約し、サーバーの帯域幅を節約できます。

現在、GreasemonkeyとTampermonkeyの両方が*.meta.jsファイルを自動的に検索するため、通常は個別に指定する必要はありません。

それで、@downloadURLや@updateURL？を明示的に指定する理由

  1. スクリプトは、複数の方法で、または複数のソース（カットアンドペースト、ローカルにコピーされたファイル、セカンダリサーバーなど）からインストールでき、1つの「マスター」バージョンのみを維持したいとします。
  2. スクリプトの初期および/またはアップグレードダウンロードの数を追跡する必要があります 。
  3. @downloadURLは、ユーザーがスクリプトを入手した場所を記録/伝達するための便利な「自己文書化」方法でもあります。
  4. 何らかの理由で、*.meta.jsファイルをユーザースクリプトとは別のサーバーに配置する必要があります。
  5. おそらくhttpとhttpsの問題です（いつかこれを掘り下げる必要があります）。
  6. あなたは悪人であり、あなたが制御するサーバーからのある将来の日付でスクリプトが悪意のあるバージョンを更新するようにしたい-それはスクリプトがインストールされた場所ではない。


GreasemonkeyとTampermonkeyのいくつかの違い：

（警告：私はしばらくこのすべてを確認していません。Tampermonkeyは常に改善されているため、変更される可能性があります（Greasemonkeyも大幅に変更されます）。）

  1. Tampermonkeyでは、現在のファイルと新しいファイルの両方に@versionディレクティブが必要です。これは、Tampermonkeyがアップデートが利用可能かどうかを判断する方法です。

    Greasemonkeyもこのメソッドを使用するため、自動更新するスクリプトに常に@versionを含めます。

    ただし、Greasemonkeyでは、更新ファイルが新しいことも必要です。また、バージョンが存在しない場合、Greasemonkeyは日付のみを比較します。これは過去のGreasemonkeyで問題を引き起こし、多くの異なるマシンが正しい日付と時刻で正確に同期されていると愚かに仮定していることに注意してください。

  2. Greasemonkeyは、デフォルトではhttps://スキームからのみ更新しますが、オプションでhttp://およびftp://スキームを許可するように設定できます。

  3. どちらのエンジンも、file://スキームからの更新を許可しません。

39
Brock Adams