RIAの実現を考えた時、現在のブラウザ上で
実装をしようとすると様々な制限があります。
デスクトップ環境との対話(ローカルリソース
インタラクション)などはその最たる例です。
そうしたことは既に何度もこのブログで触れて
きていますが、ここ最近の非ブラウザタイプの
リッチクライアントを見ていて、改めて大きな
ポイントに気がつきました。
それは「ブラウザは元来アプリケーションを
ホストすることを意図して作られていない」
ということです。例えば、サーバーサイドの
サーブレットコンテナは設定の異なる複数の
アプリケーションを稼動させる仕組みを仕様
のレベルで備えています。ですが、ブラウザ
が扱うのはあくまでページであり、アプリを
区別しているURLはページのロケーションの
違いでしかありません。URLを識別子にして
アプリ毎に異なったセキュリティポリシーを
設定するくらいは可能ですが、アプリの寿命
に相当するキャッシュ制御などをきめ細かく
指定することはできていません。
IBMがEclipseRCPを採用したり、AdobeがAIRを
投入したりしたのも、Webアプリケーションの
基本設定やライフサイクルを管理する仕組み
がクライアント側にも必要だと考えたからだと
思います。
リッチクライアントでは何らかの手段でモジュール
をクライアントPC側にも配置するのが通常ですから
そうした仕組みが必要になるのは良く考えてみれば
当然のことです。
ただし、ここで一つの問題が生じます。
非ブラウザタイプのリッチクライアント実行環境を
使った場合でも、従来のWebコンテンツは今まで通り
正しく表示されなければなりません。HTMLを解釈し
レンダリングする技術は多くのノウハウ蓄積を必要
とします。
先に上げた二つの技術はいずれもその課題をうまく
解決しているようです。EclipseRCPの場合はSWTで
IEコンポーネントをラッピングしたものを備えています。
一方のAIRはAppleのWebKitを内臓しています。
このように考えると、近い将来「ブラウザ」は
レンダリングエンジンとUIとの分離がより明確
に意識されるようになるのではないかという気
がしています。
そして、さらにUI部分はアプリケーションホスト
の部分とその上で動作するアプリ毎にカスタム化
されたUIとに分離してくるでしょう。
アプリケーションホストの部分が中心となって、
その上で動作するアプリ毎に適切なレンダリング
エンジンを取捨選択できればさらに理想的です。
そこまでくると、アプリケーションホスト部分は
OSと一体化し、デスクトップアプリとWebアプリの
区別がほとんどなくなってしまうかも知れません。
その時のレンダリングエンジンはデバイスドライバ
に近い位置づけといった感じでしょうか？
EclipseRCPやAIRの進化の方向性はWebアプリや
ブラウザだけでなく、今後のOSの在り方にまで
少なからぬ影響を及ぼす可能性があるのではと
考えています。
