FluxMozilla関係の情報に特化したブログです。Connor氏に対する独占インタビューを掲載している。3.2"という記事で、2月10日付けだ。3.2を補強する三つの柱』で紹介した内容と重複する。それを除いても三点の重要なポイントが見られた。3.2のリリース時期である。順番に検討していこう。記事によれば、Connor氏は、MozillaがUbiquityをロケーションバーに統合することを目指していると述べたようだ。Ubiquityのコア機能をFirefoxに組み込むと明らかになったときから予想されたこととはいえ、Connor氏のブログ記事では明言されていなかったところであり、確定させた点に意味がある。Ubiquityをロケーションバーに統合するプラン自体は、『UbiquityはFirefoxの一部となれるか』で既に紹介した。複数のデザイン案が提示されているが、どれも一長一短ある。Ubiquityの長所を生かしつつ、自然な形でFirefoxのUIに溶け込ませるのは容易ではない。Raskin氏が発表するであろう続報を待ちたい。Connor氏は、Ubiquityを統合することにした理由として、Firefoxの次期バージョンでは、速度の向上といった漸進的な改良ではなく、もっと純粋なイノベーションを求めていたこと、Ubiquity自体に対する反響が大きかったことを挙げている。Chromeと違い、「タブごとに独立したプロセスを割り当てる手法」を採用しない。2009-01-27』)。3.2でもこの手法を採用しないと明言した。理由は、タブごとに生じるメモリのオーバーヘッドが、累積すると無視できない量になるからである。「メモリを共有するほうが効率的だ」とConnor氏はいう。同時に、ドメインごとにプロセスを割り当てる可能性を示唆した。Gmailのタブはすべて一つのプロセスで走らせるといった形だ。Connor氏の影響力を考慮すれば、この示唆は重要である。3.2のリリース時期さすがに、リリース時期についてはConnor氏も明言を避けている。4ではないと思う」としている。現在、次のリリースを年内に出すか、それとも翌年の春に回すかを決めようとしているところだという。ここでおさらいしておこう。3.1はもともと5〜9か月のスパンで開発される「マイナーリリース」の予定だった。かかるメジャーリリースよりも短い期間でリリースするものだったのである。3.2のリリース時期が翌年の春になるとすると、開発期間は丸一年となり、メジャーリリースに近い扱いとなる。一年の間にその扱いに見合うだけの機能を追加できるかというと、それも難しい。3.1に多くの新機能を投入したことで、ハードルが上がってしまったからだ。実装予定の機能を増やせば、不確定要素も増える。一年の予定がさらに伸びることも大いにありうる。3.2は、追加する機能を少なくする一方、開発期間も短くするのが現実的ではないだろうか。3.1が4月中にリリースされるとして、3.2を年末にもってくるのはスケジュールとして妥当なところだ。4の開発をどうするのかという問題が残る。大きな変更を加えずにバージョンアップしていくスタイルは、リリース時期の管理には便利だが、イノベーションを妨げるデメリットもある。対策の一つとして、どこかの時点でTrunkを複線化することが考えられよう。マイナーリリースを開発するためのTrunkと、メジャーリリースを開発するためのTrunkを分け、後者にはかなり実験的なパッチの投入も認めることにすれば、Firefoxの進化を止めることもないはずだ。管理コストは相当かかるが、Mozillaはそれに耐えるだけのリソースを備えつつある。潤沢な資金を人材と設備に回せば充分に実現可能と考えるが、どうだろうか。はてなブログProMozilla関係の情報に特化したブログです。ZoneMoz-Fxりんごが好きなのでぃすとりかごとなり。@abp_jpUnreviewednorah'#Firefox更新情報Wikiブログ日々のつぶやきスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。