メインコンテンツへスキップ

開発ロードマップ

1998年10月26日 Brendan Eich

Mozilla ブラウザ 開発ロードマップへようこそ。最新の FAQ に対する回答は ここ をクリック。

経験上、充実したロードマップは、歴史にもとづいた注意書きと 見る価値のある助言を含んでいます。 ソフトウェアの詳細なロードマップは、それがたどってきた状況を 組み込み続けなければ、すぐに役に立たないものになってしまいます。 この種のロードマップは、設計上の決定や、その根拠を記録しています。 さらに重要なことに、このようなロードマップは、(非現実的な) 改良された アーキテクチャから始めて普通の実装に進むよりむしろ、予想しなかった 良い状況や期待していなかった工夫の出現を反映します。

略歴

わたしが、 mozilla.general ニュースグループに、 Mozilla ブラウザの開発スケジュールについての 当時の考え を投稿してから５ヶ月以上になります。 スケジュールは、ただひとつの大きな部品、すなわち mail/news の組み込みを挙げ、 残りを挙げていくのは後に延期しました（他にいい考えもなかったので...）。

それ以来、すべての mozilla.org 開発者たちによって、たくさんのすばらしい作業 がなされました。 すなわち、警告（を発する問題）とバグの修正、コードの移植（porting）と 整理（cleaning up）、性能の向上、ダウンロード可能なクローム（chrome）の洗練、 autoconf ビルドシステムの作成、などなど。 しかし、Netscape からの mail/news のコードは、今だに間にあっていません。 コンテンツ開発者にもっとも求められている機能（reflow による インクリメンタルレイアウト、修正された CSS、レベル１ DOM）を、 古いコードベース上に実装することは困難でした。 そして Emacs やその拡張言語風の "hook を単に追加" したかった開発者たちは、彼らの希望に反して、 古いレイアウトと FE コードが非常に扱いにくいものであることに気づきました。

さぁ、そして今、私達は、より良いアイデアをたくさん持っているのです。

私達が向かうところ

古いレイアウトと FE コードベースに頭を悩ませるのをやめるときがきました。 私達は、それらの表現手段を捨てて、人々がほんとうに期待していたより さらに有益なものを手に入れました。 私達の手には今、何百ものトップウェブサイトを見ることのできる、すばらしい 新レイアウトエンジン があります。 私達は、XPFE による コンセプトの実証（proof-of-concept）を確信しています。 長く続いた問題の束を解決するために、これらふたつの新しいプロジェクトを Mozilla で使わない理由はありません。以下のすべてが、Mozilla ブラウザプロジェクトに、XPFE と NGLayout を使うときがきたといっています。

  • module owners の判断

  • ウェブコンテンツ作者達の熱意

  • mozilla.org の技術顧問としてのわたしの個人的判断

多くのバグだけでなく、不足も解決され、完全なメールクライアント、 ユーザースクリプタブルな（user-scriptable）hook、 そして多くの他のクライアントやプロキシのようなモジュールを よりよくサポートできるようになります。

XPFE と NGLayout に移行することは、すべての旧式 FE と、もちろん、 mozilla/lib/layout やその仲間たちをしまい込むことを意味します。 古いレイアウトコード、XFE、 そしてそのほかの FE でコーディネートされたすべての開発は、すぐに中止されます。

いくらかのものは #ifdef （でハードコーディング）されていますが、 ほとんどの back-end モジュールは、XPFE と NGLayout を使って進展し続けていること、 すなわち、NGLayout によってすでに多くの作業が進められていることに注意してください。 私達が古いレイアウトや FE を意図的に破棄しなかったとしても、 新旧のレイアウトに共通しているすべての back-end モジュールの進化は、 古いコードベースを陳腐なものにしてしまいます。 私達はすでに、しまい込みや掘り返しを容易にするために、CVS の mozilla ツリーに MozillaSourceClassic_19981026_BASE のラベルをつけました（逆行する開発のための MozillaSourceClassic_19981026_BRANCH というブランチタグもあります）。

改めて イントロダクション

このドキュメントは、mozilla ブラウザ開発の物語風なロードマップとしての役割を 果たすでしょう。ここには、履歴やプロジェクトの状況に言及するスケジュールが 書かれるべきかもしれませんが、そうはなりません。 開発上のルール、いいかえれば、私達が採用しようとする設計の原則、 すなわち XPFE、NGLayout、そして XPCOM を使ったモジュール方式（modularity using XPCOM） の価値を踏まえてビルドすることを述べます。 主な作業項目を列挙します。そしてわたしは、現実を反映するべく、何度も更新します。

このロードマップに書かれている、いずれの事柄も（確かな履歴は別として）、 変更されないものとして受け取られるべきではありません。 私達は決定を過度に見直すことはさけようとしていますが、 すべての開発者のコメントや修正は歓迎します。 必要なら、議論を膨らませましょう。 あなたがたが証拠と理由を与えてくれるなら、私達 mozilla.org は 方向性とこのロードマップをより実情に合ったものに修正します。

設計の原則

ここではブラウザ開発上のルールを示します。 これらのいくつかは、おおげさな原則よりさらに具体的な設計上の決定です。 しかし私達は、それらは十分なアイデアを反映する （例えば、autoconf 取り込み機能が私達の古い Unix のビルドシステムの プラットフォームマクロや、#if defined(linux) || ... のコードが テストする結果より信頼できる）と考えています。

  • 外部開発は Netscape 内部の開発者にとって、便利であったり、 気軽であったりする以上のことが期待できます。 たとえば Netscape X-heads は、そのメールの扱いの全てが I'm-out-sick-today（今日は病欠）や真に独占権のあるメッセージを除いて mozilla.unix ニュースグループに移されました。 NGLayout についても同様に、ハッカー達と mozilla.layout グループに移されました。 すべての開発がこのようになるでしょう。

  • 新鮮な mail/news クライアントが Netscape と外部開発者たちによって、 現段階ではオープンソースデータベース（わたしは Berkeley DB のようなものであることが望ましいと考えている） を使ったオープンソースの手法によって、共同で設計・実装されます。 新しい mail/news コードは、HTML レンダリングに NGLayout を使います。 それは可能な限り XPFE のような、クロスプラットフォーム ウィジェットを使うべきです。すなわち、 Ender や Shack のような、thin-mail テクニックを 使うべきです。

  • UI 構造は可能な限り、HTML や XML、そして、NGLayout エンジンを使って 実装されなければなりません。 スタイルは、次の部分では CSS を使って表現されるべきです。 すなわち、そうすることに意味があり、かつ、 CSS にスタンダードから外れた拡張を必要としない部分です。 リモートソースから（に）呼び出されたり、変更されたり、 上書きされたりすることのできる構造は、 その XML 文法で表現された RDF である必要があるかもしれません。 アクション（Actions）は、 明確なイベントとそのための JavaScript ハンドラによって実装され （るか、少なくとも実装できるようにされ）なければなりません。

  • モジュールは、プログラム化されたインタフェースを指定したり、 問い合わせたりするために、XP-IDL と XPCOM を使います。 そうすることで、すべてのモジュールは、すべてのインタフェースクリエータに、 くり返し-その上-手の込んだ スクリプトエンジン接続の手書き を強いることのないスクリプタブルなものになります。 また、システムの部品は、自動的に生成される stub (stubs) を利用して スレッド、プロセス、そしてマシンバウンダリにまたがって分散される かもしれません。 この分配の発展性は、シングルスレッド コードの制限によって apartment スレッドモデル の実装が必要な部分を除いた 遠い第２のゴールです。

  • XP-IDL を使って私達が得る scriptable-C++ entry points より上位のどの scripting hooks も IDL 拡張を使って設計されたり、指定されたりしなければなりません。 この重大な原則は、ブラウザのすべての有用な部品を スクリプトしやすくするためのものです。 さらに、イベントは、JavaScript を使った柔軟な方法で "hook" しやすく、扱いやすくなければなりません。 この点についてのより詳しいことは、 XPCOM-Connect ドキュメント に記述されます。

  • autoconf は、あなたがたが Unix 上で動作するブラウザを make するために モジュールをチェックし、全部いっしょ にビルドすることのできる、 ひとつの 真に Unix-hosted なビルドシステムになります。 Module owners は、彼らのモジュール用の Unix スクリプト Makefile.in と configure.in だけを維持（管理） すればよく、 これらに加えて gmake の Makefiles を維持する必要はありません。 （この原則は、NSPR には適用されません。 Berkeley DB が NSPR を独立ビルド必須ステータスにし続けるせいか、 結局 NSPR は、ブラウザからの独立ビルドが前提条件になっています。）

  • X-heads は、 Motif から、先行するフルオープンソースの X ベース UI ツールキットである GTK+ に移行する時期であると信じています。 ここにある一般的な原則、すなわち、 先に mail/news の段で述べた Berkeley DB の関係や そしてもちろん、autoconf 採用の背景 は、Mozilla がよく知られた問題を解決するために、 最良のオープンソースソリューションを使わなければならないということです。

主な作業項目

これから述べるそれぞれの作業（task）は、主なマイルストーンを構成しています。 このリストは、依存性をあらわすために、整理されるべきですが、 まだ部分的に整理されていません。 このリストはまた、（いずれ）相関的に分類され、スケジュールされるでしょう。 このリストは副作業（sub-task）や抜けている作業項目を含めて洗練されるでしょう。 いまのところ、このリストは、わたしが考える、 私達みんながこれから何ヶ月かのうちにやろうとしていることを 思い付くままおおまかに書き出したものです。

  • NGLayout は完成しました。 詳細なアクションアイテムとスケジュールは NGLayout プロジェクトページ を御覧下さい。

    "オープンソースソリューション" の原則に照らして、NGLayout によって使われる ウィジェットライブラリは、Motif から GTK+ に移植される 必要があります。

  • 古い composer/editor は、古いレイアウトとかたく結びついていました。 NGLayout はぜいたくな DOM API を持っていて、たぶん（よりイベントが働く） 新しいエディタの基礎を築くことができます。 とにかく、Mozilla は HTML composer/editor を装備するべきであり、 それは OBJECT や TEXTAREA TYPE="text/html" タグ を使って、組み込み可能なものでなければなりません。

  • XPFE を使った設計と実装。まだまだ準備中の 設計ドキュメントのセット がありますが、 それらは上の設計の原則と、関係する開発者たちの仕事（input）にもとづいて、 変化し、発展するべきものです。

  • RDF や JavaScript のような バックエンドモジュールは、 およそ準備ができていますが、それらの相互作用、とりわけその実行モデルの 相互作用は、分析が必要です。 また、メモリ消費や ガベージコレクターのようなものが、"全システム" の分析を必要としています。

  • Mail/news XPFE と モジュラーバックエンドは、設計・実装される必要が あり、いくつかのケースでは、mozilla/lib/libmime のような 既存の Mozilla コードから進化する必要があります。

  • すべてのインタフェースのための XP-IDL コンパイラと IDL の仕様が書かれ、 テストされ、ビルドシステムの一部として配置されなければなりません。

  • JavaScript XPCOM-Connect ランタイムがビルドされなければなりません。 それによって JS が ランタイムの type 情報を使って C++ のメソッドを call し、 結果を JS の type に変換することができます。 よいニュースは、そのうちのあるものが、LiveConnect に類似していることです。 悪い（それを楽しんでいるハッカー達にとってはよい）ニュースは、 プラットフォームが組み合わさっている部分 （cpu 命令セットのアーキテクチャ、コンパイラと cpu が決定する呼出しの慣習） では、それぞれのプラットフォームに Invoke メソッドを実装するために いくらかのアッセンブリーコードが必要なことです。

  • すべての Unix ビルドの autoconf への変換。 現在のところ、NGLayout は mozilla/nglayout.mk によって ビルドされています。 既存のブラウザ ビルドモデルを踏襲するのなら、 mozilla/Makefile.in と mozilla/configure.in から 生成される、Makefile によってビルドされなければなりません。

  • Windows ビルドでは、後の名前で統一するために、少なくとも mozilla/nglayout.mak と mozilla/client.mak が必要です。 しかし、cygwin32 があれば、Win32 でも autoconf を使うことができるようです。 おそらく、いくつかの ATL-ライクな属性はそれを妨げるかもしれませんが、 正しい結果が得られなければなりません。