Ganymede(サイト・英語) がリリースされるまであと数週間となった。人々の目はすでに E4(サイト・英語) の名前で呼ばれる Eclipse の未来へと向けられている。最近の E4 サミット(source)では Eclipse が将来向かう方向とゴールについて議論がおこなわれた。InfoQ は以前の記事(関連記事)で E4 のスコープについて触れているが、今それはさらに具体的なものになりつつある。この点において E4 という名前はバージョンナンバーというよりもコードネームといったほうがよい。また、E4 が登場する前に、来年には Eclipse 3.5 が 3.4 の後を継いで登場するかもしれない。
主な作業は、Eclipse の環境をスタンドアロンアプリケーションとしてではなく WEB ブラウザ内で実行できるようにすることだ。どうすればサーバサイド Eclipse アプリケーションを WEB ベースで表示させることができるのかは、RAP(サイト・英語) （ webinar(source)）が示してくれたが（ワークベンチデモ(source)、メールデモ(source)）、既存の Eclipse ワークベンチや IDE プラグインの大部分はユーザインタフェースに固有のハードコーディングを前提に作られている。
SWT ブラウザエディション(サイト・英語)も含めて、 SWT の将来(source)についても議論が進行中だ。RAP(サイト・英語) の現在の実装は Qooxdoo(サイト・英語) AJAX ライブラリ（デモ(source)）を使って UI をサーバから遠隔レンダリングしている。これは有効なアプローチかもしれない。もうひとつの選択肢としては GWT(source) のようなクロスコンパイルの技術が使えるかもしれない。ターゲットとなるのはブラウザ内の別の VM （ Flex(サイト・英語) や Silverlight(サイト・英語) など）かもしれないが。
もうひとつの方向性は、将来的にはスクリプティング(source)を可能にするなど、別の言語(source)でプラグインを記述できるようにすることだ。Scala(サイト・英語) がその言語のひとつとして提案されているが、JavaScript(サイト・英語) や JRuby (サイト・英語)など何らかの動的言語もサポートされるだろう。
サーバストレージを使って UI を WEB ブラウザ上にレンダリングできるようにするため、ユーザとワークベンチが一対一の関係にあるとの前提に立っている作業を分離して進める必要がある。さらに、（ EFS(サイト・英語) のような）いくつかの同期 API は、WEB ベースシステムが本来もっている非同期な性質を扱うために、非同期のコミュニケーションチャネルへと移行していく必要がある。新しいアプリケーションモデル(source)だけでなく新しいリソースモデル(source)が現在議論されており、現在の API に内在する制約（たとえばプロジェクト階層のネストができないなど）のいくつかが解決されることが望まれる。
多くの進歩があったし、そのほとんどは以前と比べて一層オープンになっている(source)。しかし、これがすべて実験的なものである(source)lことを頭に入れておいて欲しい。E4 がどのようになるべきか（またはならないべきか(source)）について、決まったルールがあるわけではない。プロトタイプのコードをダウンロードして試してみたい方は、こちらからいくつかデモが入手できる(source)。
クライアントサイドの IDE が WEB ベースのフレームワークへと発展することに対して、あなたはどう考えるだろうか？