| 要約: | - 随時接続コンピューティングにより、アプリケーション ユーザーは Web サーバーに接続していないときでもアプリケーションにアクセスすることができます。
- OCC アプリケーションはユーザー マシン上にそれ自体のコピーを作成します。
- アプリケーションの OCC 機能を使用するかどうかはユーザーが制御します。
|
Curl 言語と Curl 実行環境は随時接続コンピューティング (OCC) をサポートしています。 OCC により、アプリケーションのエンド ユーザーはローカル ハード ディスクにアプリケーションのコピーを保存して、Web サーバーに接続していないときにはこれにアクセスできます。Curl 実行環境は、保存されている Curl ソースおよび他のアプリケーション データを使って OCC アプリケーションをローカルで実行します。
エンド ユーザーの観点から見た OCC シナリオは次のようになります。
- エンド ユーザーは通常のネットワーク URL の前に特別な curl://occ/ URL プレフィックスを使い、Web アプリケーションに接続します。Web サーバーとの接続が確立されているので、ユーザーは通常のネットワーク URL にリダイレクトされます。ユーザーは通常のネットワーク URL を直接使うこともできますが、Web サーバーに接続されていない場合に適切な OCC 動作を得られないので、特別な URL プレフィックスの使用が推奨されています。
- アプリケーションはユーザーに対し、ユーザーのローカル ハードディスクに無制限でデータを書き込む許可を求めます。このデータには、アプリケーションのソース コード自体のローカル コピーが含まれます。ユーザーはこの要求を却下することができ、その場合はこのアプリケーションの OCC 機能が無効になります。
- ユーザーが許可を与えた場合、ユーザーのハードディスクにアプリケーション (ソース コードと関連データの両方を含む) がコピーされます。許可は永久に有効であり、したがってアプリケーション (ソース コードおよび/またはデータ) を将来更新するときには、ユーザーに再度許可を求める必要はありません。
- この後で Web サーバーに接続されていないときに、ユーザーは前と同じ方法で通常の URL の前に curl://occ/ URL プレフィックスを使い、アプリケーションにアクセスします。ユーザーはアプリケーションのローカル コピーにリダイレクトされます。ここでユーザーはアプリケーションの完全な機能 (Web サーバーへの接続を必要とする機能を除く) を使って作業できます。現在のインターネット キャッシュの内容によっては、通常のネットワーク URL でも正常に作動する場合があります。ただし、キャッシュの内容は常に変化する可能性があります。もちろん、この URL では失敗する場合もあり、さらにこの方法では、せっかくローカルに作成されたアプリケーションのコピーを使用することは絶対にありません。アプリケーションがこの状況を検出して、ローカル コピーの使用を推奨することはできますが、これが適切ではない場合があります。
- さらに時間が経過した後で、ユーザーは再び通常の URL の前に curl://occ/ URL プレフィックスを使い、アプリケーションにアクセスします。ただし、このときは Web サーバーに接続されています。ユーザーは通常のネットワーク URL にリダイレクトされます。アプリケーションは、ユーザーが最後にローカル コピーを取得した後でアプリケーションが更新されたことを検出し、自動的にローカル コピー (ソース コードおよび/またはデータ) を更新します。ここでユーザーは何も行う必要がありません。この更新によって、ユーザーが次回に Web サーバーから切断された場合でも、更新された機能を使うことができます。
エンド ユーザーは、アプリケーションのネットワーク 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 アプリケーションの記述では、いくつかの点を考慮する必要があります。
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-install-or-update プロシージャの使用における適切な
installer プロシージャの組み合わせに関与しています。
{curl 6.0 applet}
{applet
manifest = "manifest.mcurl",
curl-root = "."
}
{do {occ-install-or-update occ-root-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.txt と curl-archive.car ファイルが存在し、したがってこのディレクトリ内の任意のアプレット (前述のアプレットなど) を参照すると、これら 2 つのファイルを使って、このディレクトリの内容がユーザーのローカル マシンに実際にコピーされることになります。
前のセクションで説明したように、
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 で、これはアプレットがローカル ファイルシステムで実行されていることを意味します。
Copyright © 1998-2008 Sumisho Computer Systems Corp.
All rights reserved.
Curl, the Curl logo, Surge, and the Surge logo are trademarks of Sumisho
Computer Systems Corp. 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 Sumisho Computer Systems Corp.