Adobe AIR アプリとOSネイティブなプログラムの連携
Adobe AIR
Adobe AIRとは、mixi日記で去年6月頃触れた、Adobe Flashをデスクトップに持ってきて通常のプログラムとして動作させるための仕組み。
ただし、ランタイム、すなわち一種のインタプリタ上で動作するため、OSネイティブなプログラムのように、Windows APIにアクセスしたりDLLの関数を利用したりはできない。よって、マシン語レベルで実行しないと厳しい計算処理などには向かない。
この欠点を補うため、OSネイティブなプログラムとDLL以外の方法で連携することを考える。
TCP/IPによる通信
物理的に同じコンピュータ内での連携を目指すので、ファイルの読み書きを通して同期することもできるが、何とも前時代的なので却下。タイミングを合わせるのも難しかろう。
AIRアプリに許された外部との通信はTCP/IPを用いたもののみ。それならば、OSネイティブなプログラムでローカルホストに適当なサーバを実装し、そこへAIRアプリからアクセスすればよい。
複数言語によるプログラミング
さて、プログラムの開発フェーズで、デザイナとプログラマを分離するために、複数のプログラミング言語を使うやり方は、これまでにもいくつか出てきている。
| Webアプリ | Mozilla系プログラム | WPF系プログラム |
|---|---|---|
| 文書の内容を構造化するためにHTML | プログラムの機能を実装するためにCあるいはC++など | プログラムの機能を実装するために.NET Framework 3.0、あるいはSilverlight |
| 見た目をデザインするためにCSS | インターフェースを定義するためにXUL | インターフェースを定義するためにXAML |
| それぞれを連携させるためにJavaScript | それぞれを連携させるためにJavaScript | プログラム本体のコンパイル時に連携、あるいはSilverlightならJavaScript |
しかしながら、どの場合をとっても、簡易にプログラムを作ろうとすればOSの機能が制限され、それをフルに活かすには最低でも三つの言語が必要だった。
Qtをはじめとするクロスプラットフォーム用の優秀なフレームワークを使えば、どんなOSでも動くソースコードを一つの言語で全てを記述できて処理も高速だが、デザインと機能を分離しづらく、ソースコードが読みにくくなりがちだし、実行ファイルのサイズが大きくなる。
今回のようにAdobe AIRとOSネイティブなプログラムを連携させる場合、ActionScript(≒JavaScript)と、CあるいはC++言語さえ知っていれば、インターフェース部分をAIRで設計し、それ以外の処理をOSネイティブなコードで実行できる。
また、OSの機能の一部がPOSIXで標準化されたりしているおかげで、インターフェース以外の大部分は各種OSで共通のソースコードを使える。この点でも、Adobe AIRにインターフェースを任せて内部処理をCあるいはC++で書くやり方は都合がいい。
なお、Webアプリの開発に使える言語のみを用いてデスクトップ用のアプリケーションを開発できる環境(gOS、AIR OS…？)がそのうち整うことが予想されるが、まだ先のことだろうし、それらがコンピュータに搭載される単一のOSとして浸透するかと言えば、極めて怪しい。デュアルブートあるいはバーチャルマシンとしての実装は、もしかすると普及するかもしれない。
以上の考えに基づき、連携の具体例の一つとして、とあるデスクトップエージェントの設計概要をここに公開する。
デスクトップエージェント"CRENO"の設計
システムの核をなす処理を行うプロセスをC-カーネル、インターフェースとしてユーザとのやり取りを行うプロセスをC-シェルと呼び、カーネルとシェルの間は専用のプロトコル(STTP)で通信を行う。
カーネルとシェルは各々基本的には独立して動作するが、シェルはカーネルへのアクセスに失敗すると強制終了する。カーネルはシェルからのアクセスを待ち受けるほか、Web経由のSTTP通信にも応答するよう設計される。
それぞれ以下の概要で開発を進めることとする。
C-シェル
- Adobe AIRによるランタイム実装
- OS間のユーザーインターフェースの違いを吸収
- カーネルとユーザ、二つのサーバに仕えるクライアントとして動作
「伺か。」をはじめとするSSTPサーバ・クライアント群と考え方は似ているが、
- サーバとクライアントの開発環境を言語仕様の向き不向きにより完全に分けた点
- 結果としてサーバとクライアントを全く別のプロセスとして開発する点
で完全に趣を異にする。
この本質的な違いにより、
- クロスプラットフォームをはじめから視野に入れて開発する
- カーネル及びシェルの根本的な差し替え(着せ替え)
といったことが可能になる。
STTP(Streaming Text Transfer Protocol) については、
- ラスタ画像を特定のフレームレートで切り替えて再生する旧来のアニメーション
- ベクタ画像を関節定義などをもとに動的に変形、レンダリングするアニメーション
- 同様に3Dのモデリングデータを動的に変形、レンダリングするアニメーション
以上、三種のアニメーションを定義する Streaming Text for Animation (STA) の通信に使われる新しいプロトコルとして仕様化する。Webとの連携も鑑み、HTTPとある程度互換性を持った仕様を想定している。
