Latest topics - outsider reflex

第5回ブログメディア研究会に参加してきたよ

ITmedia Biz.ID 第5回ブログメディア研究会に行ってきた。

参加者の簡単な自己紹介の後、最初はMozillaがどういう組織であるかやFirefox登場の経緯などの説明が一通りあって、次に、Firefox 3で検討されている様々な新しいUI、特にダンさんが担当しているPlaces関係の話が、モックアップのスクリーンショットを交えてなされた。

DevConとかに参加してたり最新情報を追っかけたりしてると、このあたりの事はだいぶ「まあ、前にも聞いたよね」な部分があったので、僕は置いてあったコーラやらお菓子やらを一人つまんでた。

その後でやっと、自由質問の時間になったわけなんだけど。

皆さんがまともな質問をする中、一人だけひねくれた質問しまくって浮きまくってた気がする。主賓のダンさんがFirefox 3（のGUIに関わる部分の）開発の担当であって全体の統括だとかXULRunnerだとかGeckoエンジンだとかの担当ではないということだったんだけど、そんな事はお構いなしに全然関係ない事を聞きまくった。まったく迷惑極まりないですね。

以下、質問も回答もぶっきらぼうな書き方だけど、これは要約したからこうなっただけであって、別に先方が一字一句その通りに答えたわけではないので、その点はご注意ください。

Q. PlacesはSQLiteベースで動いているという事だが、そこに独自のカラム（フィールド）を追加する事はできるのか？　例えば、あるページを訪問した際に「どこのページからそこにやってきたか」という情報をデータベースに格納する事で、Web Mapのような機能を実現できる可能性はあるのか？

A. 独自のカラムを追加する事は推奨されない（もしかしたら、できない？）。その代わり、注釈やコメントを付けるためのカラムはあるので、それを使うとよいだろう。

Q. Safari 3のインライン検索のような機能は入らないのか？　アレはよいものだ……

A. 予定にはない。（この回答に対して、補足として、検索でヒットした箇所以外を暗くする事は見栄えがよいということ以上に人間工学的･認知学的観点からも、検索結果の把握のために効果的であること、そういう観点からの検討も忘れないで欲しいという事を偉そうに付け加えておいた。）

Q. Places、ブックマーク、履歴などの検索クエリに正規表現は使えないのか？（UIとしてではなく、APIとして。XUL/Migemoのような拡張機能が利用できるような。）

A. 詳しくは調べてみないと分からないが、多分できない。

Q. 「バグが報告されてから修正されるまでの日数」とは、バグが報告されてからどの時点までの日数をカウントしているのか？　パッチがチェックインされた時？　Nightly Buildが利用できるようになった時？　それとも2.0.0.4のようなセキュリティフィックスが公式にリリースされた時？

A. 2.0.0.4のようなセキュリティフィックスが公式にリリースされるまで。

Q. エンドユーザの要望は時に、開発者のモチベーションを奪う事があるし、開発者が喜ぶような変更が、エンドユーザにとってはありがたくない結果になる事もある。Mozillaはエンドユーザにとっての幸福と開発者にとっての幸福のどちらを最終的に優先する方針なのか？

A. バランスの問題だが、少なくとも、開発者が楽をするためだけにエンドユーザに苦労をさせるような決定はしない方針である。

Q. （一つ前の質問のより突っ込んだ質問として）Firefoxの開発はオープンソースの開発者コミュニティに支えられており、開発者のモチベーションを高く保つようにしないと成り立たない。よって、一概に「エンドユーザ優先」と言いきれないのではないか。――という話を前提にした上で再度伺うが、Mozillaはエンドユーザと開発者のどちらを優先する方針なのか？

A. 即答はできない。とても難しい問題だ。

Q. すべての描画をcairo経由で行うという方針のせいで、ドロップシャドウ系の効果はもはや実装できそうにない（cairoグラフィックライブラリの開発者がボカシなどのエフェクトを実装する事に否定的なので）と聞いている。この問題についてはどう思うか？

A. cairoにとってMozillaはかなり大きな「顧客」であるから、いつの時点での事になるかは分からないが、将来的には、こちらの要求する機能はcairo側で一通り備えてもらう事になると考えている。（この件については僕の方から、SVGエディタのInkscapeもcairoをバックエンドとして使用しようという動きがあるらしいという事、各方面からの突き上げが増えればcairo開発陣も方針を変えるのではないかと期待している、と付け加えておいた。）

Q. オープンソースなライブラリであるcairoを使っているがために前述のような問題が出ているわけだが、それについてどう思うか？

A. だからといってそれを解決するためにクローズドソースの物を取り込む事はできない。Firefoxを構成する物は基本的にすべてオープンソースでないといけない。（つまり、どうやら、「オープンである事」がFirefoxの本質に近い部分で大きな「価値」であり、それを損ねる選択は可能な限り避けなくてはならない、と捉えられているようだ。）

以下、さらに時間外に聞いた内容。

Q. APIがFx 3で変わる事、さらにその先のFx 4でも変わる事がすでに「予告」されている現状では、拡張機能の作者が「Fx 1.5からFx 2への更新でAPIが変わったから対応しなきゃ、と思っているうちに、Fx 3でまたAPIが大きく変わると聞いたから、じゃあFx 3が出るまで待とう。え、Fx 4ではもっと抜本的にAPIが変わるの？　じゃあFx 4まで待つか……」という風に「乗り換え控え」を起こしてしまうのではないか？

A. FUELがそういったFirefoxのバージョン間のAPIの差異を埋めるライブラリとなる予定である。

Q. FUELにそのような役割が期待されているのは分かったが、FUEL自体が長期に渡ってメンテナンスされることが成功の条件になるだろう。きちんとメンテナンスが継続されるかどうかについて不安なのだが？

A. それは今後の課題。

Q. FUELやその他のライブラリがFirefoxのbrowser.xulの構造に特化した構造になっていると、ちょっと変わった拡張機能を作る時にはもう使えなくて困る（例えば分割ブラウザのような、Firefoxの構造を変えてしまうような物では、nsSessionStore.jsは使えない）。ライブラリを作る時はスケーラビリティやフレキシビリティを高く保つようにしてはもらえないか？

A. それも検討しないといけない課題。しかしFUELは拡張機能開発の初心者を意識しているので、なるべくシンプルなAPIを目指している。そういう特殊な、より踏み込んだ機能を持つ拡張機能の開発については、at own riskでやってもらうしかない部分が大きい。

予定の質問時間を僕のせいでだいぶ無駄にさせてしまった気がする。他の人もたくさん質問を出されていたので、後から回答をもらえるかもしれない……とのことだったが、さて、どうなるのだろうか。

追記。cairoが駄目なんだったら独自のライブラリを新しく作ればいいじゃない、というツッコミを見かけたけれども（ブログメディア研究会においてではない）、慢性的な人手不足のMozilla開発コミュニティにそれを期待するのは現実的には厳しすぎるだろう……と思った。特にハードウェアアクセラレーションやなんかが絡んでくると、他より一層高いレベルの技量と知識が要求されるんじゃないだろうか。CoreGraphicsを丸ごとWindowsに移植してきたAppleはよっぽどそこに金を投じたんだろうなあ。

追記2。当日の様子が記事になってる。