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

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

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

注意: 7.0以前では、OCC URLのプレフィクスは、curl://occ/でしたが、これからは、以下で説明されているcurl://offline/シンタックスになります。curl://occ/URL シンタックスは、非推奨（deprecated）になりましたが、以前のCurlリリースと整合性を保つ為に維持されます。新しいアプリケーションにはcurl://occ/は使用しないでください。
エンド ユーザーの観点から見た OCC シナリオは次のようになります。
エンドユーザーは、アプリケーションのネットワークURLの前に特別なCurl URLプレフィクスcurl://offline/を書くことで、アプリケーションにアクセスすることが出来ます。例えば、シンプルなOCCアプリケーションであるhttp://www.curl.com/developers/occ2/app1.curlは、アドレスバーやハイパーリンクで、curl://offline/http://www.curl.com/developers/occ2/app1.curlとして参照することが出来ます。アプリケーションは、自身をインストールしようとするか、既にインストールされている場合は、ローカル コピーにリダイレクトします。
ローカル コピーの実際の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}
アプリケーションは、この場所に依存すべきではありません。いかなるアプリケーションコードにおいても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.curl の applet ステートメントには curl-root = "." 宣言が含まれているので、その "curl root" は http://www.curl.com/developers/occ2 になります。
例 (2) : アプレット http://www.curl.com/developers/occ2/subdir/app2.curl の applet ステートメントには 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 プロシージャの組み合わせに関与しています。
非常に簡単な installer は occ-root-installer で、前述のサンプル アプレットだけでなく、次の非常に簡単なアプレットでも使われています。
{curl 8.0 applet}
{applet 
    manifest = "manifest.mcurl",
    curl-root = "."
}
{do {occ-install-or-update occ-root-installer}}
...
このアプレットは、参照されるたびにそのローカル コピーのインストールまたは更新を行ってから、通常どおりに実行します。
occ-install-or-updateプロシージャは、まず最初に、アプリケーションがローカルにインストールする許可を持っているかどうかを確認します。ユーザーのマシンに既に存在しているアプレットのローカル ルート ディレクトリを呼び出すと、occ-install-or-updateは、過去に許可が得られていると解釈し、アプレットのインストール、更新を行うためにinstallerプロシージャを呼び出します。アプレットがまだ、ローカル ルート ディレクトリを持っていない場合には、occ-install-or-updateは、アプリケーションのインストールの許可を求めるダイアログを表示します。アプリケーションが、キーワード引数を使用して、詳細情報を与えていない限り、occ-install-or-updateは、request-local-data-permissionを呼び出して、Yes-Noダイアログを表示させます。アプリケーションが、install-filenameキーワード引数を記述している場合は、許可を求めるダイアログは精巧になり、成功したインストールは、ネイティブ アプリケーションのようにホスト オペレーティング システムに登録されます。それには、ランチャーアイコンが含まれ、またプラットフォームがサポートする場合には、アンインストールオプションも含まれます。
上記のアプレットでは 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.txt と curl-archive.car ファイルが存在し、したがってこのディレクトリ内の任意のアプレット (前述のアプレットなど) を参照すると、これら 2 つのファイルを使って、このディレクトリの内容がユーザーのローカル マシンに実際にコピーされることになります。
より複雑な installer は occ-module-installer ですが、この使用例はまだ用意されていません。

特別なURL

OCCアプレットは、ネットワークに接続されているかどうかに関わらず、常にローカル ファイル システムから起動されます。アプレットの基本URLは、ローカル ファイルシステムURLになります。インストールされたアプリケーションの元のサーバーのアプリケーション ルートとホスト名はセキュリティ目的で使用され、ネットワーク接続がある場合には、curl://http-rootを通じてアクセスすることが出来ます。ローカル アプリケーション データは、curl://local-dataを通じてアクセスされます。

OCCのディプロイメント

前のセクションで説明したように、occ-root-installerは、アプレットのcurl-rootに特別なcurl-timestamp.txtと curl-archive.carファイルを持っているサーバーに依存します。occ-module-installerは、またこれらのファイルにも依存し、更に内部モジュールの依存性を示す為に特別なcurl-modules.txtファイルを使用します。IDEから、これらのファイルを生成することができるディプロイメント ツールを使うことができ、またOCCの管理をすることができます。

接続ステータスの確認

アプリケーションは、network-disconnected?プロシージャを使用して、 ローカル コンピュータの現在の接続ステータスを確認できます。 この情報を使い、インターネット リソースへのアクセスなど、ネットワーク接続を必要とするすべてのアクションを適切に処理することができます。
Copyright © 1998-2019 SCSK Corporation. All rights reserved.
Curl, the Curl logo, Surge, and the Surge logo are trademarks of SCSK Corporation. that are registered in the United States. Surge Lab, the Surge Lab logo, and the Surge Lab Visual Layout Editor (VLE) logo are trademarks of SCSK Corporation.