JP2005533312A - 手持ち型クライアント・フレームワーク・システム - Google Patents

Abstract

【課題】 手持ち型クライアント・フレームワーク・システムを提供し、さらに、複数のクライアント・プラットホームにわたって容易にサポートされるプログラミング言語を提供すること。
【解決手段】 手持ち型クライアント・フレームワーク・システムは、ネットワーク・アクセス可能な情報のためのクライアント要求に応え、要求された情報を供給するために最も適切なサーバを決定し、かつインターネットおよび／またはイントラネットにわたってそのサーバに情報要求パケットを送るサーバ・プロキシ・クライアントを提供する。情報要求に対するサーバ応答は、サーバ・プロキシ・クライアントにより受信される。サーバ・プロキシ・クライアントは、応答情報を適切なデータ構成要素に分離する。データ構成要素は、適切なクライアントに送信される。プレゼンテーションおよび論理構成要素は、クライアント上のワン−ビハインド・キャッシュに一時的に格納される。クライアントは、現行のユーザ要求に応じるために、すでにインストールされた、またはワン−ビハインド・キャッシュのプレゼンテーションおよび論理構成要素を使用し続けるであろう。サーバ・プロキシ・クライアントにより送信された、および前記ワン−ビハインド・キャッシュに格納された任意のアップデートは、ユーザによる次の使用で、クライアントにより検索される。クライアントの状態は、ユーザが、例えば、有線の接続からワイヤレス接続に変わるとき、クライアントがドロップされないように、サーバ・プロキシ・クライアントにより保存される。本発明は、ホストが、いつでも、クライアントの動作を修正する、または新しい機能を加えることを可能にすることにより、クライアントの論理構成要素を供給し、かつクライアントに無制限の柔軟性を与えるスクリプト言語を含む。

Description

本発明は、パーソナル電子デバイスにおけるデータ配信および変換に関する。より詳しくは、本発明は、適合できるプロトコルおよびサーバ・プロキシ・クライアントを使用して、パーソナル・デバイスにネットワーク全体にわたって利用可能なデータを検索かつ送信することに関する。

パーソナル・データ・デバイスは、今日の技術主導型社会の一般的なアクセサリになった。PDA、テキスト・ページャ、携帯電話およびパーソナルコンピュータが最初に市場に入ったとき、各デバイスは、それ自身のカスタマイズ・アーキテクチャを備えていなければならなかった。初期のシステムは、多数の通信およびオペレーティングシステムの標準への道を開いた。

しかしながら、多種多様なデバイスによって、ソフトウェア業界に問題が生じた。アプリケーションプログラマは、それらのプログラムを各デバイスのオペレーティングシステムおよびディスプレイ能力に移植しなければならない。例えば、あるPDAは、Palm OSを使用する160×160ピクセルの白黒ディスプレイを有する可能性があり、一方、他のものは、WinCEを使用する180×240のカラーディスプレイを使用している。

アプリケーションプログラマは、彼のプログラム用のユーザ・インタフェースを作成するとき、各デバイスの制限を考慮しなければならない。デバイス間の異なるグラフィクス能力は、例えば、様々なプラットホームにわたってGUIの同じルック・アンド・フィールを達成することを極めてむずかしくする。アプリケーションプログラマは、あるデバイスに容易に表示される何かが、他のものに表示されない可能性がある、または2つのデバイス間で同じものに見えない可能性があることを考慮しなければならない。

CPU速度は、また、アプリケーションプログラムにも影響を及ぼす。アプリケーションプログラムの効率は、プログラムが実行可能となるように各プラットホーム向けに微調整されなければならない。ユーザは、彼らのパーソナル・データ・デバイス上で遅いプログラムを使用したくない。

加えて、パーソナル・デバイスは、利用可能なメモリおよびクライアントソフトウェアがROMに格納されるか否かで非常に変化する。RAMの量が少ないと、データを管理することがむずかしくなる。一方、ROMに格納されたクライアントソフトウェアを有することが、普通の消費者にとって不可能でないとしても、アップグレードすることをむずかしくする。

これらの制限の全てが、アプリケーションプログラマに関する問題を引き起こす。

異なるパーソナル・データ・デバイスをサポートするためにプログラムの多くの異なるバージョンを生む結果、それは、異なるコードベースをサポートする観点から途方も無く厄介な問題を引き起こす。各コード・バージョンは、デバッグ、アップデート、およびサポートされなければならない。データパケット・プロトコルまたはオペレーティングシステムが変わるとき、そのシステムのためのコードベースは、変わらなければならない。

一つの具体例は、サーバおよびクライアントのXMLウェブ・サービスを一緒にリンクしようとするマイクロソフト社の.NETフレームワークである。.NETフレームワークは、全てのサーバおよびクライアントが、XMLを使用して通信し、かつXMLの情報を転送することを必要とする。この結果は、XMLサービスのしっかりと織りこまれたネットワークである。しかしながら、このアプローチは、クライアント・デバイスが、ユーザにより要求され、かつ表示されているデータの全ての局面を処理することを必要とする。それは、また、各異なるプラットホーム用に提供され、かつサポートされるアプリケーションプログラムを必要とする。加えて、アプリケーションプログラムの複雑さが増加するにつれて、クライアントシステムの処理デマンドは、より強力なプロセッサを必要とする。

ホストシステムから容易にアップデート可能な(updateable)クライアント・フレームワークを提供し、かつクライアントシステムの処理デマンドを減らす手持ち型クライアント・フレームワーク・システムを提供することは、有利であろう。複数のクライアント・プラットホームにわたって容易にサポートされるプログラミング言語を提供する手持ち型クライアント・フレームワーク・システムを提供することは、更に有利であろう。

本発明は、手持ち型クライアント・フレームワーク・システムを提供する。システムは、ホストシステムから容易にアップデート可能であり、かつクライアントシステムの処理デマンドを減らすクライアント・フレームワークを提供する。さらに、本発明は、複数のクライアント・プラットホームにわたって容易にサポートされるプログラミング言語を提供する。

本発明の好適な実施例は、ネットワーク・アクセス可能情報(network accessible information)のためのクライアント要求に応えるサーバ・プロキシ・クライアントを提供する。サーバ・プロキシ・クライアントは、要求された情報を供給するために最も適切なサーバを決定し、かつインターネットおよび／またはイントラネットにわたってそのサーバに情報要求を送る。

情報要求に対するサーバ応答は、サーバ・プロキシ・クライアントにより受信される。サーバ・プロキシ・クライアントは、応答情報を適切なデータ構成要素に分離する。データ構成要素は、適切なクライアントに送られる。プレゼンテーションおよび論理構成要素は、クライアント上のワン-ビハインド・キャッシュ(one-behind cache)に一時的に格納する。クライアントは、サーバ・プロキシ・クライアントによって、クライアントが、当面の特定の作業のためのプレゼンテーションおよび論理構成要素の最新バージョンを使用していることを確認する。クライアントが最新バージョンを使用していない場合、それは、サーバ・プロキシ・クライアントからのアップデートを要求する。クライアントは、現在のユーザ要求に応えるためにワン-ビハインド・キャッシュの中に現在存在するプレゼンテーションおよび論理構成要素を使用し続けるであろう。サーバ・プロキシ・クライアントにより送信され、かつワン-ビハインド・キャッシュに格納される任意のアップデートは、ユーザによる次の使用でクライアントにより検索される。

クライアントの状態は、ユーザが、例えば、有線の接続からワイヤレス接続に変わるとき、クライアントがドロップされないように、サーバ・プロキシ・クライアントにより保存される。ユーザは、サーバ・プロキシ・クライアントによりクライアントを再認証する必要がなく、かつユーザのセッションは、あたかも割込みがなかったかのように、続く。

本発明は、ホストが、いつでも、クライアントの動作を修正する、または新しい機能を加えることを可能にすることにより、クライアントに無制限の柔軟性を与えるスクリプト言語を含む。設定された機能は、クライアントが出荷した後のステージにおいてサーバ・プロキシ・クライアントから配備されることができる。クライアント・スクリプトのアップデートは、サーバ・プロキシ・クライアントにより、クライアントに送られる。

本発明の他の観点および利点は、例えば、本発明の原理を示す添付の図面と組み合わせて、以下に記載する詳細な説明から明らかになるであろう。

本発明は、手持ち型クライアント・フレームワーク・システムにおいて実施される。本発明によるシステムは、ホストシステムから容易にアップデート可能であり、かつクライアントシステムの処理デマンドを減らすクライアント・フレームワークを提供する。さらに、本発明は、複数のクライアント・プラットホームにわたって容易にサポートされるプログラミング言語を提供する。

本発明は、クライアントシステムの動作および外観を動的に変える柔軟性をホストシステムに与えるスクリプト言語およびクライアント・エンジンを提供する。クライアント・エンジンは、異なるクライアント・アーキテクチャおよびユーザ・インタフェースに容易に適応できる。ホストシステムは、クライアントシステムによりアクセスされるデータの大部分のデータ処理を実行するプロキシ・クライアントを含む。

図1を参照すると、本発明は、PDA、テキスト・ページャ、携帯電話およびパーソナルコンピュータ102、103、104のようなポータブル（およびノン・ポータブル）デバイス上で実行するアプリケーションのためのホスト制御可能なアーキテクチャを提供する。セッションのデータおよびプレゼンテーション面を分離するサーバ・プロキシ・クライアント101も、また、提供される。その各々は、例えば、プレゼンテーションから独立した使用のために、データがプレゼンテーションなしで利用可能であるように、クライアント102、103、104に独立して送られる。クライアント・デバイス102、103、104は、有線のネットワーク105、電話回線106、またはサテライト／ワイヤレス接続107を介して、サーバ・プロキシ・クライアント101に接続可能である。

サーバ・プロキシ・クライアント101は、クライアント要求のデータをインターネットおよび／またはイントラネット108を介して得る。データは、サーバ・プロキシ・クライアント101により受信され、かつクライアント102、103、104に送られる前にクライアントにより必要とされる基本的なデータに処理される。データを表示するプレゼンテーション面は、サーバ・プロキシ・クライアントに別に格納され、かつ特定のクライアント・アプリケーションに特有なディスプレイ特性を表す。データおよびプレゼンテーションの構成要素の分離は、クライアント102、103、104が、他のディスプレイ・フォーム用のデータを再利用すること、または他のアプリケーション用のデータを解釈し直すことを可能にする。

本発明は、また、永続的なプロキシ・クライアント（すなわちサーバ・プロキシ・クライアントのプロキシ・クライアント構成要素）も、クライアント102、103、104に関する状態を維持するサーバ・プロキシ・クライアント101において提供する。このことは、例えば、ユーザが、Ethernet（登録商標）のような1つのトランスポートからRicochetのような他のトランスポートに状態を失うことなく、またはユーザを再認証する必要がなく、切り替えることを可能とすることにより、可用性を改善する。

本発明は、上記したように、クライアント・フレームワークおよびサーバ・プロキシ・クライアント101から成る。クライアント・フレームワークの目標は、ホストにより修正可能なクライアントの動作を有することにより、最大限の柔軟性を提供することである。このことは、焼き付けられた(burned in)そのクライアント・コードを有するPDAのような、クライアント・コードを直接アップデートする可能な手段を有することができないであろうプラットホームに新しい機能を速やかに追加することを可能にする。

本発明は、プレゼンテーション、論理およびデータ構成要素を分離することにより、この柔軟性を達成する。このことは、各構成要素が独立してアップデートされることを可能にし、したがって、ネットワーク・トラフィックおよびサーバに対する余分な要求を削減する。さらに、このフレームワークは、共通な、最適化されかつ試験されたコードベースを有することにより、新しいクライアントのための開発時間およびバグ・カウントを減らす、いくつかのプラットホームにわたって活用可能である。

サーバ・プロキシ・クライアント101は、クライアント102、103、104からの全ての要求を処理し、かつ一様なプロトコルで応答を戻す。このことは、HTTP、IMAPおよびSMTPのような複数のデスクトップ中心のプロトコルの理解を、もはや必要としないクライアント102、103、104の応答性を非常に単純化する。追加的な機能は、それらが開発され、かつオンデマンドで、クライアント102、103、104により受信されるとき、サーバ・プロキシ・クライアント101から配布される。

本発明は、Palm OS、WinCE、Linux、マッキントッシュおよびWindows（登録商標）のようなさまざまなプラットホーム上にホスト制御されたクライアントを構築するための共通のフレームワークを提供する。一旦、ROMに焼きつけられたクライアント・コードを有するデバイスが顧客にリリースされると、最善でも、クライアントをアップデートすることはむずかしい。本発明のフレームワークは、この問題、およびポータブル・デバイス上にクライアントを作成することに伴って含まれる他のいくつかの困難さに対処する。

フレームワークの主な目標は、サーバ・プロキシ・クライアントが、クライアント・コードをアップデートする必要なく、クライアントの動作および機能設定を制御し、かつ修正することを可能にすることである。また、共通のフレームワークは、共通な、最適化され、かつ試験されたコード・パスを共有することによりバグ・カウントおよび開発時間を減らすために、クライアント開発により活用可能である。

本発明の基本アーキテクチャは、クライアント・データ、プレゼンテーションおよび論理を、XMLデータモデルを使用して異なった構成要素に分離する。クライアントが、サーバ・プロキシ・クライアントに要求を行うとき、サーバ・プロキシ・クライアントからの応答は、そのコンテンツの意味情報を保存するバイナリシリアル化された(binary serialized)XMLデータストリームとして伝わる。このことは、スクリプトにより定義されるクライアント論理が、応答の特有な構成要素を識別し、修正を行い、および任意の様式でデータを利用することを可能にする。さらに、クライアントに送られるデータは、プレゼンテーションから独立してキャッシュ可能であり、このことは、それが、あとでクライアント論理によって、他のフォームにより再利用されること、および任意の様式で表示、または再解釈されることが可能であることを意味する。

図2を参照すると、株式相場要求201に対する応答は、各々名前を付けられた値のツリー202として戻る。この情報202は、ディスプレイの要求の所望の構成要素のみを引き出すためにクライアント上の論理により使用されることができる。

クライアントのプレゼンテーション構成要素も、また、オブジェクトおよびプロパティからなるXMLデータストリームである。プロパティは、整数、ストリングおよびブール値のように単純である、またはスクリプト、またはイメージの画素データを含むことができるバイナリまたはニュース記事のリッチ・テキストのように複雑であることが可能である。オブジェクトは、ボタン、テキストフィールド、またはポップアップメニューのようなUIウィジェットであることが可能であり、top、left、heightおよびwidthのような組み込み整数プロパティを有する。追加的な組み込みプロパティは、キャプションまたはコンテンツに関するストリングを含む可能性がある。

ネイティブ・アプリケーションは、フォント、サイズ、色およびスタイルのようなネイティブの機能をよりよく利用するために特有のプラットホームを考慮して意味をなす組み込みプロパティを加えることができる。この柔軟性は、データストリームのその一様な取り扱いにおける本発明の設計に固有である。

図3を参照して、データモデルは、これらのオブジェクトおよびプロパティ301を、現在のフォームに含まれる個々のウィジェットのレイアウトを示す単一のツリー302として表す。

ユーザがフォーム上のボタンを押すとき、それは、サーバ・プロキシ・クライアントに要求、例えば株式相場を送るスクリプトをアクティブにすることができ、および会社名および時価を引き出し、かつテキストフィールド・プロパティにポピュレートする(populate)ためにそれらの値を使用するためのサーバ・プロキシ・クライアントの応答のコンテンツを取り扱う論理を有する。しかしながら、元のフォームは、このサービスの将来の要求がすぐにフォームを表示するように、クライアントによりキャッシュされる。しかし、ユーザが、株式相場のための異なる記号またはマップを得るための異なるアドレスを特定するような対話型の要求をすることを、なお可能にする。これらのフォームまたは機能は、クライアントに焼き付けられず、むしろ、サーバ・プロキシ・クライアントによりクライアントに利用可能とされる。

本発明のアーキテクチャは、下記で説明される、クライアントの論理構成要素を供給するスクリプト言語を含む。スクリプトは、フォームにおいてまさに別のプロパティのように見えるが、それは、インテリジェントな動作をクライアントに提供する。ユーザがプレゼンテーションのボタンを押すとき、ボタンと関連しているスクリプト・プロパティが、（後述するように）実行する。スクリプトは、フォーム上の入力を確認することから、サーバ・プロキシ・クライアントに要求し、所望の部分を応答から引き出し、かつプレゼンテーションの適切な場所にそれらを挿入するためにオブジェクトにより呼出されるまで、多くの作業を実行することができる。それは、また、サーバ・プロキシ・クライアントからの特有な応答用の調整をするために、UI構成要素の位置を修正することが可能である、または、特定のクライアントのディスプレイ制限を満たすために、応答におけるデータを修正することができるであろう。

スクリプト言語は、サーバ・プロキシ・クライアントが、いつでも、クライアントの動作を修正し、または新しい機能を加えることを可能にすることにより、クライアントに無制限の柔軟性を与える。設定される機能は、もはや、クライアントのための開発問題ではなく、その代わりに、サーバ・プロキシ・クライアントからクライアントが出荷した後のステージにおいて配布されることができる。

アクティブなクライアント側論理を有することの他の利点は、サーバ・プロキシ・クライアントに接続を有することなく、その機能性の多くを提供するクライアントの能力に現れる。したがって、クライアントは、不連続または紛失カバレージ(coverage)の間に、なお実行することができ、およびサーバ・プロキシ・クライアントに接続を有することは、ユーザが、彼が不連続または紛失カバレージの間、どこで終わるかを選択可能とすることにより、ユーザ経験を更に強化する。最後に、クライアントをサーバ・プロキシ・クライアントからアップデートする能力は、クライアント・コードを直接アップデートすることが可能でないとき、或るバグがスクリプトにより対処されることを可能にすることにより、クライアントの耐久性および堅牢性を強化する。

本発明の強みは、それが、それらのリリースの後に、修正され、かつアップデートされることが可能なクライアントを開発する手段を提供することである。この点は、控えめに述べられてはならない。それは、あたかも本発明がプレゼンテーション・パッケージであるかのように、現れるかもしれないが、このことは、本発明が、プレゼンテーション、データおよび論理を必ず区分するという事実から生じる。この際、クライアントの関数および機能は、サーバ・プロキシ・クライアントからクライアントに利用可能とされた本発明のフォームにより定義される。クライアント上のアクティブな論理は、設定されるその機能が、単一のHTMLより非常に豊富であり、かつその特定のクライアントに合わせてなお調整されることを可能とする。加えて、本発明の内部構造体は、デベロッパーが、特有なクライアントに必要かつ適切な部分のみのインスタンスを生成し、軽量および堅牢なクライアントを迅速かつ効率的にもたらすことを意味する。

本発明のフレームワークを利用するクライアントを構築することは、2つの主要なファセットを含む。第1に、システムのカーネルには、オペレーティングシステム(OS)を通常経由しなければならないデバイスの或る共通の機能にアクセスする手段を与えられなければならない。第2に、クライアントのネイティブ実装は、プレゼンテーション層のサポートが望まれる場合、デバイスで利用可能なユーザ・インタフェース・ウィジェットを定義しなければならない。

図4を参照すると、本発明のフレームワークは、5つの層401に分割される。プレゼンテーション層402、本発明のNachosオブジェクト404およびシステム・オブジェクト403を含むオブジェクト層、オブジェクト・ランタイム層405、トランスポート抽象407および記憶抽象406を含む抽象、およびブートストラップ・アプリケーション層408。

ブートストラップ・アプリケーション408は、本発明のカーネルのネイティブ実装を含み、およびトランスポートおよび記憶のようなデバイス上の動作に必要なフック(hook)を実施する。ブートストラップ・アプリケーション408は、デバイスに特有なサービスを公開するためにランタイムにオブジェクトをインストールすることができる。この層408は、本発明に関連していない追加的な機能性のホストを務めることができる、または、本発明によりまだサポートされない他の機能を組み込むことができる。これに代えて、それは、通信のようなデバイス特有な問題を処理する単一の「グルー(glue)」層として働き、かつ本発明のプレゼンテーション層402からクラスを派生することにより、ユーザ経験の大部分を実施することができる。

本発明は、NachosSystemInterfaceと呼ばれる抽象基本クラスを定義する。クライアントは、この基本クラスからクラスを派生させなければならず、かつ本発明のフレームワークとデバイスのネイティブのOS間とのグルーを提供する全ての仮想関数を定義する。このクラスの仮想関数は、基本のファイルシステムを定義する記憶関数、AOLへパケットを送る手段、そのデバイスのためのイメージ表現、およびUTCにおける現在時刻に対するアクセスを含む。これらのメカニズムによって、本発明は、データベース内のキャッシュおよび永続的な記憶のような必須の関数を提供する。この記憶は、RAM、フラッシュメモリの形で、またはデスクトップ・クライアント上のハードディスクの形でさえ、実施されることができるであろう。本発明は、ネイティブコードが供給する実施について仮定を行わず、それがNachosSytemInterface基本クラスにおいて説明される様式で動作することのみを仮定する。クライアントがこれらなしで機能することができるにもかかわらず、要求および選好に応じることは、クライアントを非常に低速にするであろう、または他の情報は、セッション間で保存されることができないであろう。

本発明のネイティブ実装を開発する第二部は、ユーザ・インタフェース(UI)構成要素の集積化を必要とする。本発明は、ボタン、編集および静的テキストフィールド、イメージ、チェック・ボックス、ポップアップメニュー等のような共通のUIウィジェットの抽象表現である一組のプレゼンテーション・オブジェクト402を定義する。ネイティブのクライアントは、本発明が定義する全てのウィジェットを実施するために必要とされないが、実施される任意のウィジェットは、registerClass()メソッドによってランタイム・オブジェクト405に登録されなければならない。このことは、クライアントが本発明のカーネルに任意の指示をハードコード(hard-coding)せずにその特定のデバイス上で意味をなすウィジェットのみをサポートする柔軟性を有することを可能とする。

ネイティブコードは、各ウィジェット用にそれがそのウィジェットを表示する手段を実施かつ提供するクラスを本発明の基本クラスから派生さなければならない。本発明は、スクリーン上のネイティブのウィジェットに対して、任意のヒット・テスト、作図、または変更を実行しない。その代わりに、派生クラスは、システム・ピアの作成および破棄、ウィジェットのプロパティが、ユーザの入力に起因して変わったという通知、および基本クラスにウィジェットがクリックされた、または選択されたことを通知する能力のようなイベントを処理しなければならない。本発明がネイティブのクライアント・コードの派生クラスから受信する変更および動作の通知は、その特定のデバイス上のイベントおよび入力を受信する手段を提供する。

本発明のアーキテクチャは、また、クライアントとの通信の全てを単一のプロトコルに統一することによって、クライアント・アプリケーションの応答性を単純化するために、サーバ・プロキシ・クライアントを特定する。このことは、複数のプロトコルを解析する必要性を除去することにより、クライアントのサイズおよび複雑さを減らす。それは、また、クライアント・コードをアップデートする必要に代え、新しいプロトコルが、サーバ・プロキシ・クライアントに変更を行うことにより対処されることができることを意味する。

本発明は、それを本質的に堅牢するように設計された。本発明の階層上のどのようなネイティブの動作も、クライアントを損なうことができない。同様に、それが任意の予想外のデータ、バイトコードまたは不正アクセスを見つけ出す場合、本発明の仮想マシン(VM)は、現在のスクリプトを中止するだけであろう。なお、このような複雑な環境に対して全ての条件をテストすることは、不可能ではないが、困難である。以下のものに限定されないが、スクリプト・コンパイラ、スクリプト・ランタイムVMおよびメッセージ・センターを含む、本発明のほとんどの面に関連する統計値およびデバッグ情報を記録するいくつかのコンパイラ・スイッチがある。

クライアントは、オプションとして、本発明によってアクセス可能なローカル・データベースを維持することができる。このデータベースは、状態情報、ユーザ選好およびローカル・キャッシュを維持するために、セッション間で永続的な記憶としての役割を果たすであろう。

サーバ・プロキシ・クライアントは、全てのクライアントに対する通信の唯一のポイントになるであろう。そのアーキテクチャは、堅牢かつスケーラブルでなければならない。サーバ・プロキシ・クライアントは、それがクライアントに送るデータストリームを作成するために、バックエンド上の任意の数の他のサーバと通信する。しかしながら、多くのクライアントは、サーバに直接接続せず、その代わりに、なんらかの無線ネットワークを通じて通信するであろう。クライアントとサーバの両方とも、重大な待ち時間およびカバレージの欠如または不連続カバレージのような問題の原因となる。

サーバ・プロキシ・クライアントは、本発明のためのメンテナンスの中心的なポイントになる。一旦、クライアントが配布されると、それは、その機能性の大部分に対してサーバ・プロキシ・クライアントに依存する。クライアントのためのコンテンツの開発は、要求および応答データストリーム・フォーマットの定義、個々の要求を処理するサーバ構成要素、およびデバイス特有なプレゼンテーションのためのフォームを必要とする。

本発明は、軽量、クロスプラットフォーム、クライアント・フレームワークであることにより、マイクロ・クライアントに適用される制約の多くに対処する。データ、プレゼンテーションおよび論理の分離は、各構成要素が独立して維持されかつ修正されることを可能にする。クライアントの機能の大部分は、ネイティブのクライアント・コードからVMまで移動する。このため、クライアント上のエンドユーザの経験は、クライアント自体をアップデートすることなく、強化され、かつ修正されることができる。

図5には、本発明のクライアント・デバイス501およびサーバ・プロキシ・クライアント509のインタフェース展望が、示されている。データ要求は、クライアント501からプロトコルハンドラ・モジュール505に、接続性1ゲートウェイモジュール502への接続性媒体1 510によって、直接接続503によって、または接続性2ゲートウェイ・モジュール504への接続性媒体2 511によっての何れかにより、送られる。接続性ゲートウェイ・モジュールは、インターネットプロトコルへの接続性媒体のために必要とされ、次に、サーバ・プロキシ・クライアント509におけるプロトコルハンドラ・モジュール505に転送される如何なる特有なプロトコルからも変換する。プロトコルハンドラ・モジュール505は、要求メッセージを解釈し、およびプロキシ・システム・モジュール506の要求を作成する、または要求がシステム・コンテンツ（例えば、プレゼンテーションまたは論理構成要素）に対してである場合、コンテンツ記憶デバイス507からシステム・コンテンツを検索する。

サーバ・プロキシ・クライアント509におけるプロトコルハンドラ・モジュール505およびプロキシ・システム・モジュール506は、ネットワーク・ホスト・モジュール508とクライアント501との間のクライアント・セッションの現在の状態を含む。このクライアント・セッションの状態は、クライアント501とプロトコルハンドラ・モジュール505との間の接続性の状態から独立している。クライアント・セッションの状態は、再確証を必要とせずに、接続性媒体1 510、接続性媒体2 511、または直接接続503の間で、自由に移行可能であり、したがって、他のユーザに対して、セッションは中断されない。

プロキシ・システム・モジュール506は、ネットワーク・ホスト・モジュール508に対する複数の接続を管理する。プロキシ・システム・モジュール506は、プロトコルハンドラ・モジュール505が使用し、かつ実施するアプリケーション・インタフェースを提供する。データの要求は、プロトコルハンドラ・モジュール505によりプロキシ・システム・モジュール506からの応答と関連づけられ、次に、データは、本発明のプロトコルに従ってフォーマットされ、および応答は、接続性媒体1 510を通して接続性ゲートウェイ1モジュール502により、直接接続503により、または接続性媒体2 511を通して接続性ゲートウェイ2モジュール504により、クライアント501に送られる。

プロトコルハンドラ・モジュール505に対するコンテンツの要求は、コンテンツ記憶デバイス507からコンテンツ・ストリームをロードすることにより処理される。要求は、利用可能であれば、クライアント・デバイス501にキャッシュされたコンテンツの状態に関する情報を含む。キャッシュされたデータが現行の場合、クライアントにキャッシュされたデータの失効日をリセットさせる単一の応答が、送られる。キャッシュされたデータが現行でない場合、このデータは、次に、本発明のプロトコルに従ってフォーマットされ、および応答は、接続性媒体1 510を通して接続性ゲートウェイ1モジュール502により、直接接続503により、または接続性媒体2 511を通して接続性ゲートウェイ2モジュール504により、クライアント501に送られる。データがフォーマットされる前に、それは、（オンデマンドで）フォーマッティングの前にコンパイルされ、または予めコンパイルされかつ記憶デバイス507に格納される。何れのオプションが選択されるかは、オンデマンドでコンパイルすることがプロキシ・システム・モジュール506においてボトルネックになるか否かに依存している。

コンテンツは、上記したキャッシュ・スポイリング・メカニズム(cache spoiling mechanism)により、クライアント501にアップデートされることができる。コンテンツの新しいバージョンは、コンテンツ記憶デバイス507に公開され、およびコンテンツの要求がクライアント501により行われるとき、新しいバージョンは自動的にコンテンツ記憶デバイス507から検索され、かつクライアント501に送られる。コンテンツは、データ、プレゼンテーション、論理または3つの任意の組み合わせとなることができる。新しいバージョンがクライアント501に送られるにもかかわらず、プレゼンテーションおよび／または論理の古いバージョンは、エンドユーザにより経験される可能性がある待ち時間を除去するために、クライアント501により使用される。

プレゼンテーションおよび／または論理の新しいバージョンは、クライアント501上のワン-ビハインド・キャッシュに置かれる。ユーザがコンテンツを要求する次のとき、クライアント501は、バージョンがその特定のコンテンツに対して存在するか否かを調べるために、ワン-ビハインド・キャッシュをチェックする。クライアント501がワン-ビハインド・キャッシュからコンテンツを検索するとき、それはコンテンツが期限切れになったか否かを最初にチェックする。クライアント501は、プレゼンテーションおよび／または論理の現在キャッシュされたバージョンをキャッシュから常に使用するであろう。コンテンツが期限切れになった場合、クライアント501は、新しいバージョンが利用可能か否かを調べるために、プロキシ・システム・モジュール506を用いてチェックする。プロキシ・システム・モジュール506が、クライアント501が最も新しいバージョンを有することを決定する場合、肯定応答は、キャッシュされたコンテンツの失効日をリセットするためにクライアント501に送られる。プロキシ・システム・モジュール506がより新しいバージョンが利用可能であることを決定する場合、プレゼンテーションおよび／または論理の新しいバージョンは、クライアント501に送られ、かつクライアント501上のワン-ビハインド・キャッシュに置かれる。新しいバージョンがコンテンツ記憶デバイス507に公開される場合、上記したバージョン要求プロセスは繰り返す。

クライアント・アーキテクチャは、効率的、ポータブル、およびフレキシブルであるように設計される。多くの異なるプラットホームを活用するために共通のコードベースを可能とすることが、意図される。

本発明のカーネルの設計が与えられると、新しいクライアントに着手するデベロッパーは、通常のクライアント開発より、なすべきことがかなり少なくなる。本発明のカーネル自体は、アプリケーションのほとんどの論理および機能性を処理するであろう。デベロッパーは、2つの領域：UI集積化およびシステム「グルー」に主に集中すればよい。

UI集積化のために、本発明は、共通のUIウィジェットの抽象表現である一組のプレゼンテーション・オブジェクトを提供する。これらは、ボタン、長方形、イメージ、チェック・ボックス等のようなウィジェットを含む。しかしながら、これらは、単に論理的エンティティである。ターゲット・プラットホーム上のUI層にフックするバージョンによってこれらを拡張することは、クライアント・デベロッパー次第である。

プレゼンテーション・オブジェクトは、ネイティブのピアを利用する概念に基づく。すなわち、各NachosButtonのために、カーネルは、クライアント・デベロッパーがターゲット・プラットホームの所望のUIツールキットにおいてボタンを作成するためにコードを提供したことを期待する。ネイティブのボタンが、NachosButtonからピアへの変更を受け取り、かつピアからNachosButtonへユーザの対話をパスすることも、また、必要とされる。

クライアント・デベロッパーは、全てのプレゼンテーション・オブジェクトに関するクラスを実施することを必要とされない。ターゲット・プラットホーム上の所望のアプリケーションをサポートするために必要なもののみが、存在すればよい。しかしながら、デベロッパーは、適正な多くのオブジェクトを実施することを奨励される。プレゼンテーション・オブジェクトにおいてクライアント・デベロッパーにより作成される任意のクラスは、ランタイムのregisterClass()メソッドによって登録されるべきである。これは、カーネルが、クライアントプログラムの所定のバージョン用に存在するクラスにフックするために知る方法であり、およびサポートされていないオブジェクトを利用しようとしないであろう。

主な先祖クラスは、NachosUIObjectである。これは、ネイティブのピアにグルーするためのサポートを提供する。2つのより重要なメッソドは、_createSystemPeer()および_destroySystemPeer()である。これらの関数は、呼出し（_createSystemPeerの前に_destroySystemPeerへの呼出しを含む）をいつでも適切に処理しなければならない。_createSystemPeer()は、それが付けられるオブジェクトのプロパティからその初期状態を確実に得なければならない。カーネルは、ターゲット・プラットホームのUIにおいて存在を維持するために必要に応じてこれらを呼出すであろう。一般に、任意のデータおよび状態は、必要に応じてネイティブのピアを消去しかつ再形成することからカーネルを解放するために、オブジェクトのサブクラスに格納されるべきである。

NachosUIObjectのサブクラスは、NachosFormおよびNachosWidgetを含む。Nachosにおいて、NachosFormは、UIが構成されることが可能な主なコンテナである。NachosWidgetは、ボタン、イメージ、長方形等のような全てのウィジェットのための基本クラスである。NachosUIObjectのノン・ウィジェット・サブクラスは、NachosTimerおよびNachosItemsObjectを含む。

各オブジェクトは、ビルトイン・プロパティとランタイム・プロパティの両方を有することができる。ビルトイン・プロパティは、削除されることができないし、名前を変えることもできず、かつ任意の事例に存在することを保証される。オブジェクトの任意の追加的なプロパティは、その子であろう。これらは、UIオブジェクト、データオブジェクト、またはスクリプト、バイナリ、整数、ブールまたはストリングのような他のプロパティとなることが可能であろう。

図6を参照すると、本発明のオブジェクトの派生を表している典型的な階層的なオブジェクト・ツリー601は、示される。

NachosFormは、以下のビルトイン・プロパティを有する：
caption‐キャプション(caption)領域において表示するフォームのストリング・タイトル
modal‐モーダル(modal)またはノンモーダル(non-mordal)としてフォームにタグを付けるブール
keepWhiteboard‐フォームがロードされるとき、ホワイトボード上のデータを保存するためのフラグ
frozen‐これが真のとき、UIはフォームを描いてはいけない
persistent‐このフォームおよびそのデータは、それが表示されない後でさえ保存されるであろう
NachosWidgetは、以下のビルトイン・プロパティを有する：
left‐UIにおけるウィジェットの左端の配置
top‐UIにおけるウィジェットの上端の配置
width‐ウィジェットの幅
height‐ウィジェットの高さ
visible‐ウィジェットが現在見える場合、真である
enabled‐ウィジェットが「アクティブ」でかつユーザ入力に応じる場合、真である
NachosWidgetから派生する他のオブジェクトは、追加的なビルトイン・プロパティを有することができる。例えば、buttonは、ラベルthe buttonとしての役割を果たすcaption property、または長方形の塗り潰しの色を示す整数としての役割を果たすrect widgetを有する。

leftおよびtopの座標は、表示領域の絶対座標系である。フォームのキャプションのために確保されたディスプレイの任意の部分は、表示領域の座標としてカウントしない。例えば、フォーム・キャプション領域がフォームの最上位である場合、top=0はフォーム・キャプション領域より下で最初のピクセルでウィジェットを配置するだろう。

一部のUIツールキットは、絶対空間にネイティブのウィジェットを配置し、および一部はそれらの親と関連してそれらを配置する。座標の任意の必要とされた変換が、NachosWidgetとそのネイティブのピア間で行われることを保証することは、クライアント・デベロッパーの仕事である。

実施するクライアント・デベロッパーに対する他の重要な部分は、ターゲット・プラットホームに本発明を「グルー」するコードである。NachosSystemInterfaceの実施は、初期化と同時にNachosRuntimeに提供されることを必要とする。カーネルは、次に、ターゲット・プラットホームとその対話を実行するためにこの実施を使用する。これは、ローカルな記憶およびネットワーク・アクセスを含む。

記憶がターゲット・プラットホームにサポートされる場合、NachosDataStreamInterfaceの実施は、NachosSystemInterfaceから実施される追加的な必要とされるメッソドをプラスして、供給されるべきである。

本発明のスクリプト言語の典型的な仕様は、下記で示される。

導入
本発明のクライアント・フレームワークは、ホスト制御された、インテリジェントなクライアントを提供する。ホスト可制御性の概念は、静的クライアントにわたって明白な利点を提供する。それは、クライアント・コードを直接アップデートする可能な手段を有する可能性はないプラットホーム、例えば、それらのクライアント・コードを焼き付けられたデバイス上のクライアントに新しい機能の速やかな追加を可能にする。また、クライアントとの予想外の問題は、ホストからクライアントの動作を修正することにより、回避される、または除去されることができる。加えて、クライアントがホストから情報を単に表示するダムターミナルを超えるので、ホストに接続されないときでも、それは、その機能性の多くを維持する。これは、大きな待ち時間接続を有する、またはオフラインで上手く機能することを必要とするクライアントに特に貴重である。

スクリプト・プロパティ
スクリプト言語の基本的なビルディングブロックは、プロパティである。すべてのプロパティは、名前および値を有する。名前は、プロパティを参照するとき、使用されることができるラベルとしての役割を果たす。プロパティの名前は、任意の長さとなることができ、および任意のプリント可能キャラクタから成る。しかしながら、字または下線でスタートし、かつ字、数または下線の任意のシリーズが続く名前が、スクリプト言語から最も容易にアクセスされる名前である。プロパティの名前は、大文字と小文字の区別ができない。プロパティ名の具体例は、以下の通りである。
プロパティの値は、いくつかのタイプのうちの1つであることが可能である。簡単な値のタイプは、整数、ストリング、およびブールである。これらは、最も一般に使用され、およびスクリプトから直接調べられる、または修正されるであろうプロパティである。

スクリプトおよびバイナリのような、より複雑なプロパティがある。一般に、複雑なプロパティのコンテンツは、スクリプトから修正されることができないが、複雑なプロパティ自体は、移動され、コピーされ、または削除されることが可能である。バイナリ・プロパティは、イメージ、テキストの大部分に対して、およびあなたがデータの大きな「ブロブ(blob)」を有するどこにでも、使用される。

最後の種類のプロパティは、特記事項に値する。それは、オブジェクト・プロパティである。

オブジェクト
オブジェクトは、それが他のプロパティのためのコンテナとしての役割を果たすので、一意的である。全てのプロパティのように、オブジェクトは、プロパティ名を有するが、また、「クラス」も有する。クラス名により指定されるオブジェクトのクラスは、それがデフォルトでどのようなプロパティを含むか、およびどのようなタイプの追加的なプロパティをそれが含むことができるのかのような、オブジェクトに関する或る属性を定義する。

図7を参照すると、エディタ・ツールは、「untitled」702という名前をつけられた「form」オブジェクト701を作成するために使用された。フレームワークがformオブジェクト701を作成するとき、それは、除去することができない、または追加注文することができない或るビルトイン・プロパティを追加する。formは、caption 703という名のストリング・プロパティ、およびmodal 704、keepWhiteboard 705、frozen 706、およびpersistent 707という名のブール・プロパティを常に有する。これらのプロパティの各々は、（persistent 707が真の場合）一旦それが表示されるならば、その状態を維持するべきか否か、または、（keepWhiteboard 705が偽の場合）それが相互フォーム通信のためのグローバルエリアをクリアするべきか否かのような、formの特性および動作を支配する。「form」は、オブジェクト・クラスの1つの具体例であるが、多くのクラスが存在する。別の一般的なクラスは、「button」である

図8を参照すると、全てのUIウィジェットは、実際に、その外観を制御する或るビルトイン・プロパティを有するまさにオブジェクトである。button801は、buttonオブジェクト801が下記で説明される「action」メッセージ803を受信する時はいつでも呼出されるスクリプト802を有する。

図9を参照すると、form901において作成されるbuttonオブジェクト902が、示される。別のオブジェクトの中でオブジェクトを作成することにより、プロパティは、単純なリストとしてもはや示されることができない。その代わりに、form901は、今、各プロパティが、親オブジェクトにより所有される階層として現れる。button、myButton 902は、left 908という名の整数プロパティおよびそれより下のすべてを所有し、一方、formは、caption 903、modal 904、keepWhiteboard 905、frozen 906、persistent 907およびmyButton 902という名のプロパティを所有する。

コンテインメント除いて、オブジェクトの他の応答性は、メッセージ処理である。

メッセージ
通信のユニットは、「メッセージ」クラス・オブジェクトである。メッセージは、ソースオブジェクトおよびそれが送られる宛先オブジェクトを有し、かつparamertersと呼ばれるクラス「stream」のオブジェクトにおけるいくつかの追加情報を通常含む。paramertersオブジェクトは、要求または応答に必要とされる情報のためのコンテナとしての役割を果たす。例えば、スクリプトが「AOL」の株式相場を要求するメッセージを送る場合、それが送るメッセージのparamertersオブジェクトは、「aol」のストリング値を伴う「sym」と呼ばれるプロパティを有する。

図10を参照すると、サーバ1001かのら典型的な応答が、示される。この場合、parameters1002は、株式相場を保持するstream1003と呼ばれる別の「データ」クラス・オブジェクトを含む。スクリプトは、名前またはインデックスにより、これらのプロパティの各々に個々にアクセスすることができる。

メッセージは、また、送信者が、応答において受信したいオリジナルのメッセージに特に含まれた任意のプロパティを含むクラス「stream」のechoオブジェクトを有する。これは、応答の受信者に要求を生成したデータをコピーするために使用される可能性がある。例えば、メール・アプリケーションで、スクリプトは、応答が戻るとき、トランザクションにIDのマップを必要とせずに、それが応答をメールと関連づけることができるように、エコーとしてメッセージIDに沿って伝える「fetchBody」メッセージをホストに送ることができるであろう。

多くのメッセージは、対応する応答メッセージを有する。例えば、loadメッセージ要求は、replyメッセージに結果を戻す。同様に、saveメッセージは、replyメッセージと共に完成の通知を送る。ほとんどのスクリプトは、応答を待つために、ブロッキング呼出しを使用し、したがって、応答の名前は、一般に必要でない。しかしながら、送信者が、特有な応答名を必要とする可能性がある非同期要求に対してデフォルト応答名にオーバーライドすることを望み、したがって、適切なスクリプトが応答を処理することができる場合がある。これは、replyNameプロパティを所望のメッセージ名に設定することにより達成されることができる。これは、エコー・パラメータがそうであるように、オブジェクトに戻ってくる応答を非多重化するために使用されるが、より一般的でない方法であり、しばしばより使いやすい。

ランタイム・ルート
図11を参照すると、フォームが表示されるために、またはオブジェクトがメッセージを受信するために、それは、runtime1101として公知のオブジェクトにより、所有されなければならない。ランタイム(runtime)は、全てのアクティブなオブジェクトに対して階層の発信元として役立つクラス「root」のオブジェクトである。

興味がある最初のオブジェクトは、フォーム・スタック、forms 1102である。ランタイムが「form」オブジェクトを表示するとき、それは、フォーム・スタックにそれを配置することにより、新しいフォームの所有権をとる。フォームのUIウィジェットは、作成され、かつ（ブール・プロパティ、visible が、真の場合）表示されるであろう。全てのウィジェットが作成された後で、ランタイムは、フォーム「displayed」メッセージを送り、したがって、フォームは、表示されると直ちに任意の動作を実行することができる。これ以降は、フォームは、それがランタイムにより所有される限り、メッセージを送り、かつ受信する能力を有する。

servicesオブジェクト1103は、ランタイムに登録されることができる多くの機能にアクセスを提供する。それがデフォルトで提供する1つのサービスは、永続的な記憶を与えるdatabaseオブジェクト1104である。データベースは、選好、ハイスコア、またはユーザのポートフォリオまたは住所録のようにセッションからセッションへ保持されるべき他のデータを保存するために、使用されることが可能である。

services 1103の下のaolオブジェクト1105は、ホストへの接続としての役割を果たす。サーバからデータを要求するメッセージは、全て、要求に対応する適切なメッセージ名と共に、aolオブジェクト1105へ送られる。例えば、図10の株式相場は、aolに送られた「getStockQuote」という名のメッセージに対する応答であった。

trashオブジェクト1106は、削除されたプロパティおよびローカルに作成されたオブジェクトのために一時的に置かれる場所としての役割を果たす。削除されたプロパティが、サスペンドされた、またはブロックされた別のスクリプトにより参照される可能性があるので、trashオブジェクト1106のコンテンツは、全てのスクリプトが実行を完了するまで、削除されない。

whiteboardオブジェクト1107は、また、フォーム間の通信のための一時的な記憶としての役割を果たす、しかし、そのコンテンツの寿命は、異なるメカニズムにより支配される。formオブジェクトのビルトイン・プロパティの1つは、keepWhiteboardと呼ばれるブールである。ランタイムは、ランタイムが偽に設定されたkeepWhiteboardを有するフォームを表示するときはいつでも、whiteboardオブジェクト1007のコンテンツを削除する。これは、次のフォームがそれを期待している（すなわち、keepWhiteboardが真である）限り、データがフォームからフォームへパスされることを可能にする。

スクリプト概要
クライアント・デバイス上で、アプリケーションは、フォームを使用することにより機能およびサービスをユーザに示す。上記のように、フォームは、テキストフィールド、チェック・ボックス、ポップアップメニューおよびボタンのようなUIウィジェットを含む。一旦、ユーザが、ボタンをクリックする、テキストを変更する、またはリストの項目を選択することにより、ウィジェットと対話すると、フォームは、そのイベントに従って行動する必要がある。それは、適切なウィジェットにメッセージを送ることによりそうするが、それは、それ自体何も達成しない。ウィジェットは、受信されたメッセージに対応するスクリプトを有する必要がある。例えば、ユーザがそれをクリックするとき、ボタンは、「action」メッセージを受信する。ボタンウィジットがactionと呼ばれるスクリプト・プロパティを有する場合、そのスクリプトは、「action」メッセージを処理するために実行される。同様に、そのスクリプトが、株式相場を得るために、aolに「load」メッセージを送る場合、「reply」と呼ばれる応答メッセージは、時価のような相場から選択されたプロパティを表示することが可能なreplyと呼ばれるスクリプトで応答を処理することができるボタンへ送り返される。

スクリプトは、クライアントにインテリジェントな挙動を与えるフォームの論理構成要素である。サーバの上に新しいフォームを作成することにより、クライアントは、単にフォームをロードし、かつそれを表示することにより、新しいまたはアップデートされた機能性を得ることができる。このタイプの柔軟性は、クライアントの開発サイクルを短くし、およびクライアントがリリースされた後で、設定されたその機能に加えることによりその耐用寿命を増やす。

スクリプトの基本
プログラミングScriptを始めるために、スクリプトライタは、データ、変数および式を表す規則に精通していなければならない。次の数セクションは、言語のコンストラクトを定義し、およびそれらを使用する方法の簡単な具体例を示す。

スクリプトを再利用することが可能であることは、信頼性を増加し、および新しい機能を開発するために必要とされる時間を短くする。しかしながら、全てのコードが、エレガントに書かれるというわけではない、したがって、Scriptは、あなたが、C++のようにダブルスラッシュを使用してあなたのスクリプトにコメントすることを可能にする。

Cスタイルのブロック・コメントもある。著しい差は、Scriptにおけるそのブロック・コメントのネストである。これは、Cからの重大な変更である。

整数、ブール、およびストリングに対するリテラル値は、下記のように表される：

newlineキーワードは、ストリング値へ改行復帰を追加するために使用されることができる。

改行のための「n」、タブのための「t」、または2桁の16進値が続く「x」が続くバックスラッシュ「\」を有するストリングにおいてエスケープ・シーケンスを使用することも、また、可能である。

Scriptのステートメントは、改行復帰により終了される。

この言語にセミコロンはない。実際、lexerは、それが実行する最初の不規則な句読点でつかえてしまうだろう。しかしながら、ステートメントがあまりに長くなる場合、それは、その行の最後の文字としてバックスラッシュを置くことにより、次の行に続くことができる。

これは、手始めとして十分であるが、データにアクセスするために、我々は、階層におけるパスをたどって所定のプロパティへ行く方法を知る必要がある。

識別子およびパス
スクリプトは、フォーム、データベースまたはホワイトボードの中に存在するプロパティに格納されることができる、ストリング、整数、およびBooleansのような値にアクセスを可能にする。これに代えて、値は、スクリプトの実行中に存在するのみである一時的変数に配置されることができる。一時的変数は、字または下線で始まらなければならない、および字、下線または数字の任意のシーケンスにより続かれることが可能である。

パスは、階層におけるプロパティの位置を特定する手段である。ピリオドは、Unix（登録商標）のディレクトリ・セパレータであるスラッシュに似ているパス・セパレータである。基本的なパス構成要素は、明確な名前、インデックス、または名前式である。

図12を参照すると、Bart's age 1204は、以下の式で設定可能であろう。

これらの式の各々は、Bart's ageプロパティを10の値に設定した。最初の式は、スクリプトを含む同じオブジェクトのパスを始めるmeで始まる。この場合、フォーム・オブジェクト、theSimpsons 1201は、スクリプトを含む。そこからたどると、フォームは、age 1204を所有するBart 1203を所有する、simpsonsデータオブジェクト1202を所有する。

第2の式は、ピリオドでパス式を始めることによりmeの略記形式を使用する。第3の式は、パスが大文字と小文字の区別ができないことを示す。最後のパスは、スクリプトと関連していないが、フォームのトップ、theSimpsons 1201で、始まる。

今から、Bart 1203におけるannoy 1205スクリプトを考えたい。Bart 1203と関連しているLisa 1206におけるプロパティを変更するために、パスは、階層を上へ移動する必要がある。それは、以下のようにしてそうすることができる：

すべては、前と同じである、しかし、parent（または「..」）パス構成要素は、それがパスの最初の部分として現れる場合、パスを現在位置から、またはスクリプトを含むオブジェクトから、1レベル、階層をさかのぼらせる。

パスの要素にアクセスする別の方法は、プロパティのインデックスを使用することである。パスにおいて、角括弧演算子は、インデックスによりプロパティを参照するために使用される。

プロパティにアクセスする便利な別の方法は、式を使用している名前による。これは、スクリプトを直接修正することなく、スクリプトがランタイムで異なるプロパティ上で動作することを可能にする。パス名として式を使用するために、ピリオドが先行する括弧または波括弧を使用されたい。例えば：

また、Scriptの特別なオブジェクトを示すいくつかのプレフィックスがある。それらは、下記の表に記載される。

式および演算子
Scriptの最も一般的な動作は、式の値を評価することである。式は、ほとんどのプログラマおよびスクリプトライタによく知られている演算子を使用して書かれる。演算子「*」、「/」、「+」および「-」、は、それぞれ、乗算、除算、加算および減算のために使用される。「=」演算子は、代入演算子および等号演算子の働きをする、言語において2つの役目を備えている。

CおよびC++と異なって、Scriptは強くタイプされた言語でない。整数がストリング・プロパティに代入されるとき、Scriptはストリングに整数をプロモートする。整数を表すストリング値が整数プロパティに代入される場合、ストリングは代入の前に整数に変換される。ストリングが10進数を表さない場合、その時、それはゼロの整数値として扱われる。ブールから変換するとき、ストリング値は、「真(True)」および「偽(False)」であり、および整数値は、「1」および「0」である。ブールへ変換するとき、大文字と小文字の区別をしないストリング値「false」および整数値「0」のみが、falseとして扱われる。ストリングまたは整数の他の全ての値は、trueである。

代入の左辺が、存在しないプロパティである場合、そのプロパティは、式の明白なタイプとして作成され、かつ式の値を代入される。

予想通りに、優先順位の典型的なルールが、適用される。

ストリング連結演算子、「&」は、Scriptに特有である。それは、ストリングに別のものを追加するために用いることができる。

論理演算子は、「not」または「!」として書くことができる論理否定を除いて、記号ではなく語である。

比較演算子「=」は、整数にそのオペランドを変換しようとするが、左右両方のオペランドがストリングである場合、それは、大文字と小文字の区別をしない比較を実行しようとする。

或る演算子は、式を単純化するために代入演算子と連携して使用可能である。

また、インクリメントおよびデクリメント演算子はステートメントとして使用されることができるが、式レベルでは使用できない。

優先順位の順にリストされる演算子の完全なリストは、以下の通りである：

条件ステートメント
Scriptは、他の言語のような条件ステートメントを有する、しかし、ステートメントブロックは、キーワードendにより終了されることを必要とする。

文法は、以下の通りである：

注：条件ステートメントのこのフォームの具体例は、以下の通りである。

elseクローズは、また、次のようにキーワードendの前にifステートメントに加えられる可能性がある：

この構文の具体例は、以下の通りである

ScriptとC/C++の条件ステートメント間の重要な異なるものは、複数の論理式が短絡しないことである。全ての式を評価することにより生成されるバイトコードは、条件付きジャンプが続く各ブール演算子の後、チェックを挿入することより非常に小さい。これは、以下のことを意味する：

また、多くの条件ステートメントは、以下の構文を使用して、一緒に連結されることができる：

例えば：

ループ
Scriptは、ステートメントのブロックにわたる繰返しを容易にするためにいくつかのコンストラクトを与える。繰返し子の最初のフォームは、以下の構文で、固定された回数、ループを実行する：

いくつかの具体例は、以下の通りである。

ループステートメントの第2のタイプは、式が真の限り、またはそれが偽の限り、実行し続ける。

これの具体例：

おそらく、ループステートメントの最もよく知られているフォームは、繰返し変数を使用し、かつ次のように開始および最期の制限を設定するものである：

境界式は、ループの初めに、単に一回評価されるであろう。これは、下限から上限まで、またはdownキーワードが使用される場合、上限からの下限までの何れかでカウントすることができる。

Cまたは C++と同様に、ループの次の繰返しに続く、または完全にループから抜け出すステートメントもある。運命づけられていたかのように、これらは、それぞれ、「continue」および「break」ステートメントである。それらは、任意のループステートメント内で現れることができる。

ループステートメントの最後のタイプは、所定のオブジェクトおよびオプションとして特定された深さまでそれの下の子の全てにより所有された全てのプロパティに触れる。深さオプションが特定されない場合、オブジェクトのすぐ間近の子のみが訪問されるであろう。これに代えて、任意の深さの全ての入れ子にされたプロパティが訪問されることを必要とする場合、これは、infinityキーワードを使用することにより達成されることができる。最後に、プロパティは、objectsOnlyキーワードを使用してフィルタリングされることができる。これは、他のプロパティをスキップし、かつオブジェクトにわたり繰り返すだけである。

スクリプトが図6の「sleeping」にsimpsonsの全ての.busyプロパティを設定することを意図された場合、それは、以下のループによって行われることができたであろう。

これは、forms.simpsonsに含まれる全てのプロパティはオブジェクトであることに注目することにより単純化されることができ、したがって、objectsOnlyフィルタは必要でない。また、デフォルトの繰返し深さが、開始オブジェクトのすぐ間近の子を訪問するのみであるので、深さは、「1」の値に設定される必要はない。

配列
本発明は、均一なデータの大きいブロックの効率的な処理を可能にする配列プロパティを提供する。配列に格納されることができる情報の種類は、ストリング、整数またはブール値に限られている。配列は、以下の構文を使用して作成されることができる：

pathは、ローカル変数または作成される配列プロパティの名前を含む階層における所望の位置へのパスであることができる。

配列が作成された今、要素を配列に加える手段となることが必要である。配列における新しい要素を作成することは、以下の構文を有する挿入ステートメントによって達成される：

挿入ステートメントは、int_expressionにより与えられたインデックスでの式により特定される値を伴って、配列の同じタイプの新しい要素を作成する。配列は、1がベースであり、C/C++スタイルのゼロベース配列ではない。したがって、ゼロが、挿入のためのインデックスとして与えられる場合、それは、追加オペレーションに結果としてなる。

配列の要素は、括弧演算子「[ ]」によってアクセスされることができる。

配列の個々の要素は、下記で詳述されるdeleteステートメントによって除去されることができる。

プロパティおよびオブジェクトの取り扱い
個々のプロパティのコンテンツにアクセスすることは、そのプロパティへのパスを評価することにより達成されることができる、しかし、あなたがプロパティを移動、または削除したい場合、または、全てのオブジェクトを複製したい場合さえ、何が発生するのか？スクリプトは、特にこれらの種類のオペレーションのためのステートメントを有する。

オブジェクト、プロパティ、または配列要素を削除するために、deleteステートメントを使用されたい。プロパティの場合、これは、全てのスクリプトが実行を完了するまで、ゴミ箱オブジェクトへのパスにより指定されたプロパティまたはオブジェクトを実際に移動するであろう。これは、スクリプトがもはや存在しないプロパティの参照を続けることを防ぐために、または更に悪いことに、スクリプトが、それ自体、またはそれが含まれたオブジェクトを削除するときの災難を防ぐために必要である。

delete演算子は、また、配列の要素によって使用されることができる。プロパティを削除することとは異なり、配列要素は、ゴミ箱に入れられずにすぐに除去される。配列のどの要素が削除されるべきかを特定するために括弧「[ ]」演算子を使用されたい。

ソース・パスおよび宛先パスを特定することにより、プロパティまたはオブジェクトを1つの位置から別の位置へコピーするために、copyステートメントを使用されたい。copy命令に対するオプションのパラメータは、新しい位置のプロパティの名前を変えるために使用されるストリング式である宛先名、および宛先インデックス、プロパティが階層に挿入されるべきであるインデックスとして使用されることができる整数式である。宛先引数が供給されない場合、オリジナルのプロパティ名が使用される。同様に、プロパティは、オブジェクトにより現在含まれる全てのプロパティの後に、オブジェクトへコピーされる。これらのオプションのパラメータのいずれも省略することができる、しかし、両方が発生する場合、それらは、示される順序で使用されなければならない。

copyステートメントは、それがすでに宛先オブジェクトの中に存在する場合、プロパティまたはオブジェクトに上書きしない。この場合、スクリプトは、新しいプロパティをコピーする前に宛先パスでプロパティを削除しなければならない。

プロパティを階層のどこか他に入れるためにmoveステートメントを使用されたい。構文および関数は、オリジナルのプロパティまたはオブジェクトがその前の位置にもはや存在しないことを除けば、copyステートメントに似ている。

前の3つのステートメントの各々は、簡単なプロパティ（ストリング、整数、ブール、スクリプト、またはエリアス）またはオブジェクトの何れかで機能する。存在しない最後のプロパティを有するパスへ代入することは、簡単なプロパティを作成する、しかし、オブジェクトは、同じ手段により自動的に生成されることができない。オブジェクトは、所望のオブジェクトのクラス名および作成されるオブジェクトのパスおよび名前を供給することにより、createステートメントを介して作成される。

長いパスを取り扱うことは、面倒であり、かつエラーを起こしやすい可能性があり、したがって、Scriptの1つの最後の機能は、複雑なパスのショートカットを作成する能力をスクリプトライタに提供する。ローカル変数に対してオブジェクトのパスを代入することにより、変数は、パスに含まれるプロパティにアクセスする手段になる。このことは、変数が使用されるたびに、パスを再評価しないことにより性能を改善する。

ショートカットは、そのオブジェクトが階層の別のポイントへ移動される場合さへ、それらがオブジェクトに続くという点で、一意的な質を示す。

呼出しスクリプトと送信メッセージ
多くの場合、スクリプトは、ボタンがクリックされた、またはタイマーが期限切れになったというメッセージ処理するactionスクリプトのように、それがウィジェットから受信するメッセージを処理する、しかし、これらのスクリプトは、いくつかの作業を実行するために他のスクリプトにしばしば依存する。

また、データおよびフォームに対するサーバへの要求は、関数呼出しの形でしばしば書かれる。関数呼出しは、以下の構文を使用する：

スクリプトを実際に呼出す行為は、呼出しの名前によってNACHOSメッセージを構築し、かつパスにより指定されたオブジェクトにそれを送信する。

図11を再び参照すると：

この関数呼出しの最後の構成要素、annoyは、実際に、スクリプトまたは送られるメッセージの名前である。

多くの呼出しは、追加的なエコー・パラメータまたはメッセージ・オプションのないパラメータを有するだけであろう。メッセージの受信者は、これらのパラメータを検討することができる。例えば、株式相場を得るために、我々は呼出しを行うことができる：

上述の具体例において、aolは、メッセージgetStockQuoteを処理するオブジェクトである。加えて、我々は命名パラメータの最初の具体例を見る。関数に対するパラメーターリストは、コンマ区切り(comma-separated)の式のリストである。各式は、名前の後にコロンが続くであろう。この場合、symは、パラメータ名、および「aol」は、パラメータの値である。実際、各パラメータは、作成され、かつパラメータが名づけられるべき理由であるメッセージ・オブジェクト「getStockQuote」のプロパティとして、値によりコピーされる。このことは、パラメーターリストの出現順序に依存せずに、他のサイドのメッセージのハンドラが名前によりパラメータを参照することを可能にする。名前が供給されない場合、「param」と呼ばれるプロパティとしてパラメータは作成されるであろう。

別の具体例は、以下の通りである：

これは、homerオブジェクトを、homerSimpsonとしてデータベースに保存する。データベースに対するsaveメッセージは、2つのパラメータを必要とする：path、プロパティ保存するデータベースのパス、およびstream：保存されるであろうオブジェクトまたはプロパティに対するパス。これらのパラメータは名づけられるので、順序は、結果を伴うことなく、逆にすることができる。

いくつかのメッセージは、メッセージが暗号化されるべきか否か、またはシステムは、それが応答を受信しないことに起因してメッセージをタイムアウトする前に、どれくらい待つべきかのようなことを特定するために、追加されたオプションを定義する必要がある。これらのパラメータは、メッセージのオプション・ブロックに置かれることができる。

これは、ネイティブの実施に、メッセージを送る前にオプションを取り扱うチャンスを与える。カーネルにより処理されるオプションのみが、カーネルが例外を投じる前にどれくらい応答を待つべきかをミリセカンドごとに特定する「timeout」である。エコー・パラメータは、後述するように非同期メッセージのために使用される。

全ての簡単なプロパティ（例えば、ストリング、整数、ブール、バイナリ、スクリプト）は、参照ではなく値によりパスされる。オブジェクトは、通常、暗黙の参照の働きをするパスされたエリアスである。パラメータとして受信されるオブジェクトに含まれるプロパティを修正することは、オリジナルのオブジェクトを修正するであろう。エリアスを含むメッセージが、ホストに送られた要求のようにローカル階層を離れる場合、メッセージにおけるエリアスは、エリアスにより参照されるオブジェクトのコピーと置き換えられる。ほとんどの場合、これは所望の動作である、しかし、これは、@演算子を使用することによりなおオーバーライドされることができる。

時々、オブジェクトは、メッセージに応答するためにすでにコードを有することができる。オブジェクトが、所定のメッセージに応答することができ、しかし、また、同じメッセージのためのスクリプト・ハンドラを含む、このようなネイティブコードを有する場合、スクリプト・ハンドラは、ネイティブコードにオーバーライドする。仮定的に、ネイティブ・アプリケーションは、shutdown()と呼ばれるメッセージを処理するコードを有する可能性がある、しかし、スクリプトは、そのメッセージを妨害し、かつ発呼者がこのようなコマンドを出す特権を有するか否かを決定するために、使用される可能性がある。この場合、発呼者の特権を確認した後に、スクリプトは、呼出しの時点でスクリプトを中止し、かつオブジェクトがそのネイティブコードでメッセージを処理することを可能にするであろう効用関数、passMessage()を呼出すことができる。エリアスは、メッセージのパラメータとして使用されるとき、特別な動作を有する。メッセージの受信者オブジェクトがローカルな（すなわち、オブジェクトは送信者と同じランタイム・ルートの下で、どこかに存在する）場合、エリアスプロパティは、メッセージにおけるエリアスとして送られる。受信者がオブジェクトに対するエリアスを解決し、エリアスにより参照されるオブジェクトにより所有される任意のプロパティ得ることができるので、このことは発生する。しかしながら、メッセージが、ローカルな環境からはなれて送られる場合、エリアスプロパティは、それが参照するオブジェクトにより置き換えられるであろう。これによって、下にあるオブジェクトおよびそれが含むプロパティの全てがメッセージへコピーされるので、メッセージのサイズに劇的な増加をもたらすことができる。多くの場合、これは、所期の効果である、しかし、エリアスが、有線で送られるとき、解決されるはずがない場合、それは、@演算子によって永続的なエリアスとしてマークされることができる。

ブロッキング呼出し
関数呼出しのデフォルト動作は、呼出された関数が戻るまで、ブロックすることである。これは、別のスクリプトに応答を処理させるのではなく、呼出しスクリプトが結果を直接処理することを可能にする。図9を再び参照すると、株式相場の最後の値は、下記のようなライブラリ・ルーチンdebug()使用して示されることができる：

その最後のステートメントにおいて、多くのことが起こっている。最初に、getStockQuoteメッセージは、services.aolオブジェクトに送られる。応答が任意のより多くのステートメントを実行する前に戻るまで、スクリプトは待つ。一旦、応答メッセージが戻ると、後置パス、.stream.aol.lastValueは、メッセージのパラメータ・オブジェクトから所望のデータを得る。これは、ライブラリ・ルーチンdebug()を使用して示される。

非同期呼出し
関数呼出しの前に予約語asyncを入れることにより、スクリプトは、オブジェクトにメッセージを送り、かつ応答を待たずに実行し続ける。これは、関数を呼出すことよりメッセージを示すことに、より似ている。一般に、これは、別のスクリプトがメッセージに対して応答を同様に処理することを意味する。上述の具体例は、メッセージを非同期で送り、および別のスクリプトにおける応答を処理する2つのスクリプトを使用して再形成されることができる。

最初のスクリプトが、応答メッセージを待つ代わりに「finished」を示すことに注意されたい。

非同期呼出しは、ブロッキング呼出しで見つからない問題を提示する：応答を処理するスクリプトは、要求を開始したスクリプトと異なる。時々、応答を処理するスクリプトは、適切に応答を処理するために、オリジナルの要求に関連する或る情報を知っていなければならない。このような場合、エコー・パラメータは、要求から応答への情報のパスを容易にする。echoブロックにおいてパスされた任意のパラメータは、メッセージ応答へ移動され、かつ送り返される。echoキーワードは、下の通り、ブロックまたはエコー・パラメータの前に使用される：

全てのエコー・パラメータが、ネットワーク全体を往復して送られるので、エコー・パラメータは、慎重に使用されるべきである。

リターン値
returnステートメントは、スクリプトが終了に達する前に実行を終了する、または値を発呼者へパスすることを可能にする。returnステートメントが続く任意の式は、評価され、およびその結果は、現在実行しているものを呼出したスクリプトに戻されるであろう。

例外処理
Scriptは、スクリプトライタがtry/catchブロックでスクリプトにおけるランタイム・エラーを処理することを可能にする。構文は、次の通りである：

tryおよびcatchステートメント間に発生する任意のエラーは、スクリプトにcatchステートメントに続くステートメント・リストの開始へジャンプさせる。catchブロック内で、スクリプトは、パス・エラーを特定することにより、特別なオブジェクトを参照することができる。このオブジェクトは、整数プロパティ、タイプ、およびエラー番号およびエラーの短い説明をそれぞれ与えるストリング・プロパティ、メッセージを有する。

ライブラリ関数
VMは、ストリング操作および乱数発生のような一般に使用される機能のために一組の組み込み関数を提供する。これらの関数の名前は、大文字と小文字の区別をしない。しかしながら、メッセージを送る、またはスクリプトを呼出すときとは異なり、これらのライブラリ関数に対するパラメータは、名づけられないが、引数リストの出現順序に依存する。いくつかのパラメータは、以下の仕様においてリストされるように、デフォルト値を有する。デフォルト値は、その特有の関数を呼出すとき、そのパラメータを含むことによりオーバーライドされることができる。2つのデフォルトのパラメータが存在するとき、明白なタイプのパラメータが、どの値がオーバーライドされているかを識別するために使用される。これの具体例は、ソース・ストリング、サーチパターン、デフォルト開始位置、および大文字・小文字の区別を無視するブール・デフォルトを有するfind()関数であろう。3つのパラメータのみが呼出しにおいてリストされる場合、整数値は、開始位置を特定し、一方、ブールは、大文字・小文字の区別を示すであろう。

効用関数

数学関数

プロパティ関数

ストリング関数
C/C++ライブラリ関数と異なって、このライブラリの関数は、ソース・ストリングを修正しない、かつ全てのインデックスは、「0」ベースではなく、「1」ベースである。関数は、オペレーションの結果を戻すが、オリジナルの引数は、そのままに残される。多くの場合、そのことは、ソース・ストリングへ結果を代入するために必要である。（例えば、.foo = replace(.foo, " apples", " oranges")）

本発明が好適な実施例を参照して本明細書において説明されるにもかかわらず、当業者は、他のアプリケーションが、本発明の精神および範囲から逸脱することなく、本明細書において記載されるものと置換されることができることを容易に理解するであろう。したがって、本発明は、含まれる請求の範囲により制限されるだけである。

本発明に従う、異なる通信メディアにわたるクライアント・デバイスと通信している本発明のサーバ・プロキシ・クライアントのブロック線図である。 本発明に従う株価応答を含んでいるストリーム・オブジェクトの概略線図である。 本発明に従うボタン・オブジェクトの概略線図である。 本発明に従う本発明の好適な実施例の5つの層を示しているブロック略線図である。 本発明に従う本発明のクライアント・デバイスおよびサーバ・プロキシ・クライアントの好適な実施例のインタフェース展望のブロック略線図である。 本発明に従うオブジェクトの派生を表している典型的な階層的なオブジェクト・ツリーである。 本発明に従うフォーム・オブジェクトの概略線図である。 本発明に従うボタン・オブジェクトの概略線図である。 本発明に従うボタン・オブジェクトを含んでいるフォーム・オブジェクトの概略線図である。 本発明に従う株価応答を含んでいるストリーム・オブジェクトの概略線図である。 本発明に従うルート・オブジェクトの概略線図である。 本発明に従うデータおよび論理オブジェクトを含んでいるフォーム・オブジェクトの概略線図である。

符号の説明

501 クライアント・デバイス
510 接続性媒体１
511 接続性媒体2
502 クライアント・パケットを送信／受信する接続性ゲートウェイ1
503 直接接続
504 クライアント・パケットを送信／受信する接続性ゲートウェイ2
505 プロトコルハンドラ
509 サーバ・プロキシ・クライアント
506 プロキシ・システム
507 コンテンツ記憶デバイス
508 ネットワーク・ホスト

Claims (30)

1. クライアントシステム用のフレームワーク・アーキテクチャのためのプロセスであって、
   サーバ・プロキシ・クライアントを提供するステップと；
   クライアントシステムからクライアント情報要求を受信するための当該サーバ・プロキシ・クライアント上の手段を提供するステップと；
   当該クライアント要求に応える前記適切なサーバを決定するための当該サーバ・プロキシ・クライアント上のサーバ決定手段を提供するステップと；
   当該クライアント要求を当該適切なサーバに送信するステップと；
   当該クライアント要求に対する当該適切なサーバの応答を受信するステップとを有し；
   当該サーバ・プロキシ・クライアントが、当該クライアントシステム用のプロキシ・クライアントとしての役割を果たし、当該クライアントシステムのためのデータ処理の大部分を実行し；
   当該サーバ・プロキシ・クライアントが、汎用データフォーマットを使用して、データ、プレゼンテーションおよび論理構成要素を有する当該クライアントシステムをアップデートし；
   当該サーバ・プロキシ・クライアントが、当該応答のプレゼンテーション面から生データを分離し、かつ当該データを当該汎用データフォーマットに入れ；
   当該データを当該クライアントシステムに送信するステップを有し；
   当該サーバ・プロキシ・クライアントが、プレゼンテーションおよび論理構成要素のアップデートを受信し；および
   当該プレゼンテーション構成要素のアップデートが、特有なクライアント・デバイスタイプのためであるプロセス。
2. 当該論理構成要素のアップデートが、異なるクライアント・デバイスタイプ間で共有される請求項1に記載のプロセス。
3. 当該クライアントシステム上のワン−ビハインド・キャッシュを提供するステップを更に有し；および
   当該クライアントシステムが、ユーザの要求に関する任意のプレゼンテーションまたは論理構成要素のための当該ワン−ビハインド・キャッシュをチェックし；
   ユーザの要求に関する任意の構成要素が当該ワン−ビハインド・キャッシュの中に存在する場合、当該クライアントシステムは当該構成要素が期限切れになったか否かをチェックし；
   当該クライアントシステムが、前記ユーザの要求に応える当該構成要素を使用する請求項1に記載のプロセス。
4. 当該構成要素が期限切れになった場合、当該クライアントシステムが、当該サーバ・プロキシ・クライアントから前記期限切れの構成要素の任意の現行のバージョンを要求し、
   当該サーバ・プロキシ・クライアントは、要求しているクライアントのプレゼンテーションおよび論理構成要素の前記現行のバージョンをチェックし、任意の前記プレゼンテーションおよび論理構成要素がアップデートを必要とする場合、当該サーバ・プロキシ・クライアントは、任意の前記プレゼンテーションおよび論理構成要素の前記最新バージョンを検索し、かつそれを前記要求しているクライアントに送信し、および
   前記要求しているクライアントが、任意の前記プレゼンテーションおよび論理構成要素の前記最新バージョンを当該ワン−ビハインド・キャッシュに格納する請求項3に記載のプロセス。
5. 当該プレゼンテーションおよび論理構成要素のアップデートをクライアントシステムに送信するステップを更に有する請求項1に記載のプロセス。
6. 当該クライアントシステムが、ユーザに対する表示を作成するために当該データおよびプレゼンテーション構成要素を使用する請求項1に記載のプロセス。
7. 当該クライアントシステムが、当該データ構成要素を他の表示目的に再使用する請求項1に記載のプロセス。
8. 記憶デバイス上にクライアントシステムの状態を保存するための当該サーバ・プロキシ・クライアント上の手段を提供するステップを更に有し；および
   前記クライアントシステムが、接続方法を変更する、または当該サーバ・プロキシ・クライアントとのカバレージを失う場合、前記保存されたクライアントシステムの状態は、当該サーバ・プロキシ・クライアントがクライアントシステムのセッションを続けることを可能にする請求項1に記載のプロセス。
9. スクリプト言語を提供するステップを更に有し；
   当該論理構成要素のアップデートが、当該スクリプト言語で書かれ；
   当該サーバ・プロキシ・クライアントが、当該スクリプト言語で書かれたスクリプトを実行可能なバイトコードにコンパイルし；
   当該サーバ・プロキシ・クライアントが、当該クライアントシステムに当該実行可能なバイトコードを送信することにより当該クライアントシステムの機能をアップデートし；および
   当該クライアントシステムが、ユーザの入力に応答して当該実行可能なバイトコードを実行する請求項1に記載のプロセス。
10. クライアントシステムのプレゼンテーション面が、当該スクリプト言語を使用して、制御される請求項9に記載のプロセス。
11. 当該サーバ・プロキシ・クライアントおよび当該クライアントシステム間の通信が、XMLデータストリームのバイナリエンコーディングを介する請求項1に記載のプロセス。
12. クライアントシステムを動的に構成するためのプロセスであって、
    ホスト・サーバを提供するステップと；
    スクリプト言語を提供するステップとを有し；
    当該ホスト・サーバが、当該スクリプト言語で書かれたスクリプトを実行可能なバイトコードにコンパイルし；
    当該ホスト・サーバが、クライアントシステムから特有な最新のプレゼンテーション構成要素および／または実行可能なバイトコードに対する要求を受け次第、前記クライアントシステムのオリジナルのプレゼンテーション構成要素および／または実行可能なバイトコードが期限切れになったか否かをチェックし；
    前記クライアントシステム上の前記オリジナルのプレゼンテーション構成要素および／または実行可能なバイトコードが期限切れになった場合、当該ホスト・サーバが、前記クライアントシステムにアップデートされたプレゼンテーション構成要素および／または実行可能なバイトコードを送信することにより、前記クライアントシステムの機能をアップデートし；および
    クライアントシステムが、ユーザの入力に応答してプレゼンテーション構成要素および／または実行可能なバイトコードを実行するプロセス。
13. 当該スクリプトが、プログラム論理を定義する請求項12に記載のプロセス。
14. 当該スクリプトが、ユーザ・インタフェース表示を作成し、かつ制御する請求項12に記載のプロセス。
15. 当該クライアントシステムが、データおよびプレゼンテーション構成要素に分離された当該ホスト・サーバからの要求されたネットワーク情報を受信する請求項12に記載のプロセス。
16. クライアントシステム用のフレームワーク・アーキテクチャのための装置であって、
    サーバ・プロキシ・クライアントと；
    クライアントシステムからクライアント情報要求を受信するための当該サーバ・プロキシ・クライアント上の手段と；
    当該クライアント要求に応える前記適切なサーバを決定するための当該サーバ・プロキシ・クライアント上のサーバ決定手段と；
    当該クライアント要求を当該適切なサーバに送信するためのモジュールと；
    当該クライアント要求に対する当該適切なサーバの応答を受信するためのモジュールとを有し；
    当該サーバ・プロキシ・クライアントが、当該クライアントシステム用のプロキシ・クライアントとしての役割を果たし、当該クライアントシステムのためのデータ処理の大部分を実行し；
    当該サーバ・プロキシ・クライアントが、汎用データフォーマットを使用して、データ、プレゼンテーションおよび論理構成要素を有する当該クライアントシステムをアップデートし；
    当該サーバ・プロキシ・クライアントが、当該応答のプレゼンテーション面から生データを分離し、かつ当該データを当該汎用データフォーマットに入れ；
    当該データを当該クライアントシステムに送信するモジュールを有し；
    当該サーバ・プロキシ・クライアントが、プレゼンテーションおよび論理構成要素のアップデートを受信し；および
    当該プレゼンテーション構成要素のアップデートが、特有なクライアント・デバイスタイプのためである装置。
17. 当該論理構成要素のアップデートが、異なるクライアント・デバイスタイプ間で共有される請求項16に記載の装置。
18. 当該クライアントシステム上のワン−ビハインド・キャッシュを更に有し；および
    当該クライアントシステムが、ユーザの要求に関する任意のプレゼンテーションまたは論理構成要素のための当該ワン−ビハインド・キャッシュをチェックし；
    ユーザの要求に関する任意の構成要素が当該ワン−ビハインド・キャッシュの中に存在する場合、当該クライアントシステムは当該構成要素が期限切れになったか否かをチェックし；
    当該クライアントシステムが、前記ユーザの要求に応える当該構成要素を使用する請求項16に記載の装置。
19. 当該構成要素が期限切れになった場合、当該クライアントシステムが、当該サーバ・プロキシ・クライアントから前記期限切れの構成要素の任意の現行のバージョンを要求し、
    当該サーバ・プロキシ・クライアントは、要求しているクライアントのプレゼンテーションおよび論理構成要素の前記現行のバージョンをチェックし、
    任意の前記プレゼンテーションおよび論理構成要素がアップデートを必要とする場合、当該サーバ・プロキシ・クライアントは、任意の前記プレゼンテーションおよび論理構成要素の前記最新バージョンを検索し、かつそれを前記要求しているクライアントに送信し、および
    前記要求しているクライアントが、任意の前記プレゼンテーションおよび論理構成要素の前記最新バージョンを当該ワン−ビハインド・キャッシュに格納する請求項18に記載の装置。
20. 当該プレゼンテーションおよび論理構成要素のアップデートをクライアントシステムに送信するためのモジュールを更に有する請求項16に記載の装置。
21. 当該クライアントシステムが、ユーザに対する表示を作成するために当該データおよびプレゼンテーション構成要素を使用する請求項16に記載の装置。
22. 当該クライアントシステムが、当該データ構成要素を他の表示目的に再使用する請求項16に記載の装置。
23. 記憶デバイス上にクライアントシステムの状態を保存するための当該サーバ・プロキシ・クライアント上の手段を更に有し；および
    前記クライアントシステムが、接続方法を変更する、または当該サーバ・プロキシ・クライアントとのカバレージを失う場合、前記保存されたクライアントシステムの状態は、当該サーバ・プロキシ・クライアントがクライアントシステムのセッションを続けることを可能にする請求項16に記載の装置。
24. スクリプト言語を更に有し；
    当該論理構成要素のアップデートが、当該スクリプト言語で書かれ；
    当該サーバ・プロキシ・クライアントが、当該スクリプト言語で書かれたスクリプトを実行可能なバイトコードにコンパイルし；
    当該サーバ・プロキシ・クライアントが、当該クライアントシステムに当該実行可能なバイトコードを送信することにより当該クライアントシステムの機能をアップデートし；および
    当該クライアントシステムが、ユーザの入力に応答して当該実行可能なバイトコードを実行する請求項16に記載の装置。
25. クライアントシステムのプレゼンテーション面が、当該スクリプト言語を使用して、制御される請求項24に記載の装置。
26. 当該サーバ・プロキシ・クライアントおよび当該クライアントシステム間の通信が、XMLデータストリームのバイナリエンコーディングを介する請求項16に記載の装置。
27. クライアントシステムを動的に構成するための装置であって、
    ホスト・サーバと；
    スクリプト言語とを有し；
    当該ホスト・サーバが、当該スクリプト言語で書かれたスクリプトを実行可能なバイトコードにコンパイルし；
    当該ホスト・サーバが、クライアントシステムから特有な最新のプレゼンテーション構成要素および／または実行可能なバイトコードに対する要求を受け次第、前記クライアントシステムのオリジナルのプレゼンテーション構成要素および／または実行可能なバイトコードが期限切れになったか否かをチェックし；
    前記クライアントシステム上の前記オリジナルのプレゼンテーション構成要素および／または実行可能なバイトコードが期限切れになった場合、当該ホスト・サーバが、前記クライアントシステムにアップデートされたプレゼンテーション構成要素および／または実行可能なバイトコードを送信することにより、前記クライアントシステムの機能をアップデートし；および
    クライアントシステムが、ユーザの入力に応答してプレゼンテーション構成要素および／または実行可能なバイトコードを実行する装置。
28. 当該スクリプトが、プログラム論理を定義する請求項27に記載の装置。
29. 当該スクリプトが、ユーザ・インタフェース表示を作成し、かつ制御する請求項27に記載の装置。
30. 当該クライアントシステムが、データおよびプレゼンテーション構成要素に分離された当該ホスト・サーバからの要求されたネットワーク情報を受信する請求項27に記載の装置。