6月25日に予定されているEclipse Ganymede(source)のリリースにあわせてInfoQはEclipseの一連のサブプロジェクトを取り上げていく。今回取り上げるのはバージョン1.1がリリースされようとしているRAP(source)（Rich Ajax Platform）だ。InfoQはJochen Krause氏(source)にRAPとそれがもたらすことについて話を聞いた。
RAP がEclipseにもたらす機能について述べるにあたり、Krause氏はまずEclipseのユーザベースを2つに分けた。一方は開発のために Eclipse IDEやツールを使う人たちで、もう一方はEclipse Platformをベースにしたアプリケーションを使う人たちである。Krause氏はIDE/ツールユーザにとってはRAPのツールとしての機能自体だけが目立つはずで、開発ツールという考え方でRAPの機能を見ようとはしないだろうと言った。しかし、Eclipse Platformをベースにしたアプリケーションのユーザにとっては、EclipseのOSGiベースのプラグイン開発モデルやJFaceそしてウェブ利用可能バージョンのSWTを使って、リッチでAJAXが利用可能なウェブアプリケーションの構築が可能になったことを意味する。RAPはEclipse Rich ClientProject（RCP）と非常によく似た目的を持っているが、少ないAPIとウェブアプリケーションを複数のユーザが使う際に起きることを考慮していることが大きな違いだ。RAP 1.0に比べると、1.1はAPIが拡張され、SWT用のMouseEvents、JFace用のImageDecorators、プラットフォームの増強といった新機能を含んでいる。また強化されたセキュリティやウィジットの透明/半透明化といったEclipse 3.4の新機能も取り込んでいる。
Dojo、GWT、OpenLaszloのような他のAJAXフレームワークがある中でどのようなポジションにつくのか聞くとKrause氏はこう述べた。
RAP はサーバサイドにフォーカスしたAJAXフレームワークで、OSGi、Equinox、Eclipse Platformと強い関係をもっています。フォーカスする対象が違うためRAPと他のフレームワークを比べるのは分かりやすいことでありません。 Dojo、GWT、OpenLaszloはそれそれのウィジットツールキットによって優れた成果を出していますが、汎用的なアプリケーションプラットフォームを提供しているわけではありません。私たちはこれらのフレームワークが競合相手だとは思っていませんし、それどころか将来のRAPにおいてクライアントサイドのレンダリングのための選択肢となる可能性だってあります。現段階では、RAPのクライアントサイドのレンダリングはqooxdooをベースにしたものですが、これもパワフルなAJAXフレームワークです。RAPとGWTですと、両方ともJavaでコーディングして開発をおこなえますが、ランタイムモデルは全く異なっています。GWTはすべてブラウザ内で実行されるのに対し、RAPはサーバとブラウザの両サイドで実行処理が別れます。
Krause氏はまた、単一のコードからAJAXアプリケーションにでもRCPアプリケーションにでもコンパイルできるRAPの機能についても語ってくれたが、初めて耳にした時に感じるほど、それは難しいことではなかったという。AJAXアプリケーションやRCPアプリケーションへのコンパイルは、同一のWorkbench、JFace、SWT APIに対しても行われたが、ウェブアプリケーションとして実行した時、これらライブラリのウェブ利用可能バージョンは元のと代用可能なほどだったという。実行時には、アプリケーションコードはサーバでまず実行され、JavaScriptベースのUIがサーバーにイベントを送ってくるとクライアントに結果を送り返すことになる。しかしKrauses氏はRAPディベロッパが覚えておく必要のある3つのことをあげた。
- ウェブはマルチユーザ環境なので、アプリケーション状態をシングルトンのような静的なオブジェクトに保持しておく方法は問題を起こしやすい
- RAPは現在RCPのサブセットも提供しているが、RAPがサポートする範囲を超えるようなRCP機能を使いたい場合、プラグイン経由でその機能をインクルードする方法が推奨される
- アプリケーションはサーバで実行されるため、ディベロッパはユーザ一人あたりのメモリ割り当てを多く取る必要はない（これはデスクトップアプリでもひとつのベストプラクティスとなる）
次世代のSWTとして、RAPはAJAXで SWTを完全に実装することを計画している。Krause氏はすべてのプラットフォームがすべてのSWT APIをサポートしているわけではないこと、そしてSWTはデスクトップアプリケーション用途にデザインされていることを指摘した。ほとんどのSWT APIはRAPで実装がされているものの、canvas上への描画やマウス移動の検出などいくつかのものは、この分野でブラウザの拡張が行われるまで待たないといけない。他にもドラッグアンドドロップやキーボードイベントのリスナといったAPIもまだ欠けているが、これらは次のRAPのリリースに含まれる予定で、これにはSWTのJava/Flexクロスコンパイラのような他のチームからの技術がStyledTextウィジットのような複雑なコンポーネントに使われることになる。
RAPの将来の予定について、Krasus氏が注力している主な2 つの分野としてあげたのが、より多くのRCP APIを実装したRAP APIと、Eclipseプラットフォームを活用したユーザエクスペリエンスとウェブのユーザエクスペリエンスの観点でより自然なフィーリングを提供することだ。Krause氏は後者のアイディアについて詳しく話し、RAPがユーザビリティの専門家と一緒になって取り組み、ユーザとのやり取りを分析することでユーザビリティの課題を解決しようとしていると説明した。Krause氏はAJAXとRIAによってウェブとデスクトップがひとつになろうとしていることも関心のある分野として見ていて、Eclipse Draw2D APIをベースにしたウェブ環境でのグラフィックエディタを作れそうなことが分かったとも語った。
e4（Eclipse 4）との統合あるいは影響はどうか尋ねると、Krause氏はこう述べた。
ブラウザ内でIDEを動かすという使われ方にはあまり興味を感じません。JDT（Java開発ツール）は私のコンピュータ上で優れた成果をあげてますし、ほとんどのディベロッパも同じように感じていると思います。ただこれはウェブ技術が役に立つようなケースがないということではありません。たとえばタスク管理や開発プロセス管理がそうです。私はRAPがこれらの分野で何かしらの役割を将来担うと見ています。しかし今は質問に戻りましょう。EclipseプラットフォームのチームとRAPチームはEclipseCon 2008において共同でe4の発表を行い、Ganymedeのリリース直後から一緒に作業を始めることになっています。RAPはウェブを利用できるアプリケーションのための一連の技術の一つとなるでしょうが、そのための唯一のものになるとも限りません。私としては多くの異種混合が起きることを期待しています。RAPチームはマルチユーザに対応できるプラットフォームをどのように作ればいいか知っていてそれを実現することができますし、SWTチームは FlexやSilverlightのようなRIAプラットフォーム向けのウィジットをクロスコンパイリングする方法も編み出しました。より良いスタイリングも私たちが共同で注力する分野のひとつです。お話したいことはまだまだあるのですが、e4を語るにはそれだけのためにインタビューを受ける必要がありますね。