随時接続コンピューティング (OCC)

要約:
  • 随時接続コンピューティングにより、アプリケーション ユーザーは Web サーバーに接続していないときでもアプリケーションにアクセスすることができます。
  • OCC アプリケーションはユーザー マシン上にそれ自体のコピーを作成します。
  • アプリケーションの OCC 機能を使用するかどうかはユーザーが制御します。
Curl 言語と Curl 実行環境は随時接続コンピューティング (OCC) をサポートしています。 OCC により、アプリケーションのエンド ユーザーはローカル ハード ディスクにアプリケーションのコピーを保存して、Web サーバーに接続していないときにはこれにアクセスできます。Curl 実行環境は、保存されている Curl ソースおよび他のアプリケーション データを使って OCC アプリケーションをローカルで実行します。

OCC アプリケーションの使用

エンド ユーザーの観点から見た OCC シナリオは次のようになります。
エンド ユーザーは、アプリケーションのネットワーク URL の前に特別な Curl URL である curl://occ/ を置くことによって、実際のアプリケーションかそのローカル コピーに透過的に適切にアクセスできます。例えば、シンプルな OCC アプリケーションである http://www.curl.com/developers/occ2/app1.curl にアクセスするために、ユーザーがアドレス バーやハイパーリンクで curl://occ/http://www.curl.com/developers/occ2/app1.curl を使うと、このサーバーに接続されている場合はネットワーク URL に、接続されていない場合はアプリケーションのローカル コピーにリダイレクトされます。
ユーザーは、アプリケーションのローカル コピーの使用を明示的に要求することができます。この場合、通常のネットワーク URL の前に特別な curl://occ-local/ URL プレフィックスを使います。このプレフィックスは、Web サーバーに接続されているときに、まもなく接続が失われることをユーザーが知っていて、そのような切断の影響を免れるためにアプリケーションのローカル コピーの使用を開始したい場合に役に立ちます。
このリリースでは、Internet Explorer だけが Web ブラウザとして curl://occ/curl://occ-local/ の使用を直接サポートしています。別のブラウザを使用するユーザーは、サーバーに接続しているときはネットワーク URL を明示的に使い、切断されているときはローカル コピーの URL を使う必要があります。HTML ページの curl://occ/ ハイパーリンクは機能しません。
ローカル コピーの実際の URL は、プラットフォームやユーザー名、場合によってはホスト名または多様なユーザー設定などによって異なりますが、プログラムを使って判定することができます。これを行うには、アプリケーションのネットワーク URL の http:// または https:// プレフィックスを、curl://user-data/local-root-for/ に置き換えてから、Url.canonicalize を使って結果を標準化します。上記の例では、これは curl://user-data/local-root-for/www.curl.com/developers/occ2/app1.curl を標準化することになります。次の例は、現在このドキュメントを見ている皆さんのシステムにおけるこの値を示しています。

{{url "curl://user-data/local-root-for/www.curl.com/developers/occ2/app1.curl"}.canonicalize}
アプリケーション内では、この場所が常に同じであるという考えは使えません。したがって、エンドユーザーに OCC アプリケーションのローカル コピーの場所を明示的に伝える場合 (例えば、エンド ユーザーにブックマークを作成してもらい、後で Internet Explorer を使っていないときにこれを使えるようにするなど) を除き、curl://user-data/local-root-for/ で構成される URL をアプリケーション コードの内部で使わないでください。
OCC アプリケーションは、実行中に接続から切断に切り替えることはできません。 したがって、サーバーに接続している間にアプリケーションを開始して、その後途中で接続が切れた場合は、アプリケーションを再ロードするか、これを閉じて再開しなければ、そのローカル コピーを使えません。 ただし、このような切断を予想して、サーバーに接続している間に切断操作を明示的に要求することはできます。

OCC アプリケーションの記述

OCC アプリケーションの記述では、いくつかの点を考慮する必要があります。

OCC のプランニング

process-get-curl-root に説明されているように、アプレットの curl-root は、そのアプレットに「関連する」ファイル ツリーのルートを定義します。これは色々な方面に影響を与えますが、OCC のコピー動作もこれに含まれます。その理由は、OCC のインストール中にはアプレットの curl-root をルートとするファイル ツリー全体 (または、少なくともこのツリーの一部で、ユーザーが興味を示した箇所) がユーザーのマシンにコピーされるためです。
ネットワーク アプレットの場合、既定では curl-root が Web サーバーのルートであるという前提が存在しますが、applet ステートメントの内部に curl-root 宣言を含めるとこれがオーバーライドされます。通常このような宣言は、Web サーバーのルートの下に、まったく関係のないサブツリーがいくつか含まれる場合に限り必要になります。例えば、ディレクトリ http://www.curl.com/developers/occ2 は、http://www.curl.com にある他のファイルとまったく関係がありません。したがって、次の 2 つの例では明示的に curl-root を使ってこの点を強化しています。
例 (1) : アプレット http://www.curl.com/developers/occ2/app1.curlapplet ステートメントには curl-root = "." 宣言が含まれているので、その "curl root" は http://www.curl.com/developers/occ2 になります。
例 (2) : アプレット http://www.curl.com/developers/occ2/subdir/app2.curlapplet ステートメントには curl-root = ".." 宣言が含まれているので、このアプレットの "curl root" も http://www.curl.com/developers/occ2 になります。
上記の 2 つのサンプル アプレットは共通の curl-root を共有しているので、どちらか 1 つだけアプレットを参照した場合も両方のアプレットがユーザーのマシンにコピーされ、後でサーバーから切断されているときに両方を参照することができます。ある意味では、この 2 つはいずれも同じアプリケーションの一部で、普通なら 1 つのプロジェクトの下で一緒に開発およびディプロイされたものと考えられます。このような単純な状況は、occ-root-installer によって対処します (下記を参照)。
もっと複雑な状況においては、1 つまたは一連のアプリケーションにおける共通コードが切り離され、アプリケーション間の共有ライブラリが形成されます。このようなアプリケーションやライブラリは別々に開発およびディプロイされます。これらはすべて、その相互的な使用やローカル データの共有が必要になる可能性があるため、共有の curl-root が必要ですが、それぞれに独自のプロジェクトが存在し、ディプロイするのが最も簡単な方法です。このような場合、個々のアプリケーションやライブラリはモジュールであり、実際には特定アプリケーションがこれら複数のモジュールで構成されていると考えることができます。さらに、あるユーザーが実際に必要としないモジュールは、そのユーザーのマシンにコピーされない方がよい場合がよくあります。このような非常に複雑な状況には、occ-module-installer によって対処します。 (下記を参照)。

OCC の記述

OCC アプリケーションは、そのローカル コピーをエンド ユーザーのマシンに作成および/または更新するために、さまざまなテクニックを使用します。これらはすべて、occ-install-or-update プロシージャの使用における適切な installer プロシージャの組み合わせに関与しています。
非常に簡単な installerocc-root-installer で、前述のサンプル アプレットだけでなく、次の非常に簡単なアプレットでも使われています。
{curl 6.0 applet}
{applet 
    manifest = "manifest.mcurl",
    curl-root = "."
}
{do {occ-install-or-update occ-root-installer}}
...
このアプレットは、参照されるたびにそのローカル コピーのインストールまたは更新を行ってから、通常どおりに実行します。
occ-install-or-update プロシージャは最初に、アプリケーションがそれ自体をローカルにインストールする許可を持っていることを確認します。これを行うには request-local-data-permission プロシージャを呼び出し、ユーザーに対して、ローカル ディスクの特別な領域にデータを書き込む許可を求めます。さらに、アプレットがネットワークから実行されていること、他のアプレットが現在 occ-install-or-update の内部に存在しないことを確認します。これらがすべて true の場合、installer プロシージャが実行されます。
上記のアプレットでは occ-root-installer が使われています。このインストーラは、Web サーバーの curl-root ディレクトリに、適切な curl-contents.txt または curl-archive.car ファイルだけでなく、curl-timestamp.txt ファイルも存在することを前提にしています。これらのファイルは統合開発環境 (IDE) で生成することができます (下記を参照)。 ローカル コピーが存在しない場合、または curl-timestamp.txt によりローカル コピーが古いものであると判明した場合は、curl-contents.txt ファイルに記されているファイルを獲得するか、または curl-archive.car ファイルに含まれているファイルを解凍し、curl-timestamp.txt ファイルをコピーして、アプリケーションの新しいローカル コピーを生成します。
実際に、サンプル ディレクトリ http://www.curl.com/developers/occ2 には curl-timestamp.txtcurl-archive.car ファイルが存在し、したがってこのディレクトリ内の任意のアプレット (前述のアプレットなど) を参照すると、これら 2 つのファイルを使って、このディレクトリの内容がユーザーのローカル マシンに実際にコピーされることになります。
より複雑な installerocc-module-installer ですが、この使用例はまだ用意されていません。

OCC のディプロイメント

前のセクションで説明したように、occ-root-installer が機能するには、サーバー上のアプレットの curl-root に特別な curl-timestamp.txt ファイルと特別な curl-archive.car ファイルが存在する必要があります。これらのファイルは IDE で生成することができます。
occ-module-installer もこれらのファイルに依存します。さらに、モジュール間の依存性を指定する特別な curl-modules.txt も使用します。この特別なファイルも IDE で生成することができますが、その前提条件として、すべてのデリゲートcurl-root のパスから明示的に始まる相対パスを使用していなければなりません。
IDE を使い、[プロジェクト] メニューの [target-name を OCC 用にディプロイ] 項目を選択すると標準のディプロイメントが行われ、ディプロイメントのターゲット ディレクトリにこれらの特別なファイルも作成されます。このディレクトリからサーバーに、これらのファイルをその他のディプロイ アプリケーションと一緒にコピーします。OCC アプリケーションのディプロイメントを計画している場合、アーカイブはマニフェストに従って作成されるので、アプリケーションに必要なすべてのファイルとリソースが、プロジェクト マニフェスト ファイルに記述されていることを確認してください。プロジェクトのディプロイメントの詳細は「プロジェクトのディプロイメント」を参照してください。

接続ステータスの確認

アプリケーションは network-disconnected? プロシージャを使ってローカル コンピュータの現在の接続ステータスを確認できます。この情報を使い、インターネット リソースへのアクセスなど、ネットワーク接続を必要とするすべてのアクションを適切に処理することができます。
ただし、ユーザーがアプレットのローカル コピーを実行している場合は、ローカル コンピュータがネットワークに接続していても、ネットワーク接続の使用は適切でないのが一般的です。これを調べる方法の 1 つは {get-the-applet}.url.local-filename != null で、これはアプレットがローカル ファイルシステムで実行されていることを意味します。