意見や要望などなど
2009/12/19 に行われた第1回 Mozilla 勉強会において、 Jetpack に対する意見や要望、問題点などについて活発な議論がなされました。議事録をカテゴリごとに少しまとめた形でここに報告いたします。さらなるご提案やご意見などがございましたら、コメント欄、あるいはこのページを直接編集して書き加えてくださいませ。尚、ここで得られたご意見をもとにして、来年早々 Jetpack 開発チームへフィードバックしに行きます!!
Jetpack開発に対して
バグ
- Bespin :日本語が入力できない
- Firebug が 1.4 以上だとうまく動かない
- うまくエラー補足ができない
- Menu の上書きで、挙動がおかしくなるときがある
- Settings の Manifest は、storage.settings を import する前に書かなければならない
- 感覚的には import が頭にありそうだし
- Jetpack Gallery :ソースコードのサニタイズがあやしい
- Jetpack のアップデートアルゴリズムがへぼすぎる
- 現状はコードを全て比較しているだけ
- >> MD5ハッシュの比較でいいんじゃね?
セキュリティ
- Jetpack Gallery:警告画面がなくなってしまった
- 自動更新の怖さ
- Jetpack Gallery にも言えること
この API は絶対欲しい!
- パスワード系入力
- パスワードマネージャとの連携
- 以下のようにパスワードマネージャから情報を引っ張ってこれるAPI
let pass = jetpack.password.get("example.com") // pass[0].user == "my name" // pass[0].password == "password"
- 逆に、パスワードマネージャにパスワードを追加するAPIが必要か?
- パスワードを削除するAPIは?
- ツリースタイルタブを実現するためのAPIが欲しい
- 拡張と Jetpack Feature 、および Feature 同士の連携
- 双方でメッセージを送り会える仕組みが欲しい
- アイディア1:nsIObserverServiceをモデルにしたAPI
<受け取り側> jetpack.message.listen( 'onTreeItemCreated', function(aData) { return <><button>X</button></>; } ); <送出側> let myItem = ''; let responses = jetpack.message.send('onItemCreated', 'foo'); for each (r in responses) { myItem += r; } 実装するときは、nsIObserverServeiceを使うといいんじゃないか? (Mozilla内部のメッセージは拾わない・拾えないように制限する必要あり)
- アイディア2:DOMEventをモデルにしたAPI
- アイディア1:nsIObserverServiceをモデルにしたAPI
- 双方でメッセージを送り会える仕組みが欲しい
- about:xxx を自由に追加するAPI
- 独自のプロトコルハンドラを定義するAPI
- アドブロックのような、Firefox自身が行っている通信の内容に割り込む・フックを掛けるAPI
- 今XPCOMを使わないと出来ない・特権が必要な機能に対応するAPIは一通り欲しい?
- 少なくともFrozenになっているインタフェースに対応するAPIは優先して取り込んでもらいたい
- Google Chrome用のAPIと互換性のあるAPI
Google Chrome用拡張機能をそのまま移植できるようにする>>開発者の流出を防げる? - サブメニューをもう少し簡単に作りたい
- pageModsの適用対象について、例外を指定したい
- 外部スクリプトを簡単に読み込むAPI
Components.utils.import()やmozIJSSubScriptLoaderみたいな - setting API で設定できる少ない
APIポリシー
- HTML5 で出来ることは HTML5 でやる。独自のAPIは作らない。
- XPConnectは使えないようにした方がいいんじゃないのか?
使えるようにしてしまうと
=>それを使ったFeatureが出てくる
=>普及する
=>ユーザがそれに依存した生活を送るようになる
=>今更XPConnectを禁止できなくなる
というシナリオが考えられるので、今のうちに禁止した方がいいのでは? - rawも使えないようにした方がいいんじゃないの?
使えるようにしてしまうと
=>それを使ったFeatureが出てくる
=>普及する
=>ユーザがそれに依存した生活を送るようになる
=>今更rawを禁止できなくなる
というシナリオが考えられるので、今のうちに禁止した方がいいのでは? - API、ライブラリのバージョンについて
バージョン指定してAPIやライブラリを読み込む機能 like gem of Ruby
後方互換性を損なう変更をAPIに加えたくなる時はいつか絶対に来るので今から備えておいた方がよい - Firefox本体のUIの文法、作法から外れるような事も実現できるようにしていいのでは?
例:Backボタンの挙動を乗っ取るAPIなど。
Operaの「巻き戻し(Rewind)」を実現しようと思ったら、Backボタンの挙動を完全に乗っ取らないといけない。
そういうこともできるように自由度を高く。
APIとのバランスか。 - fuel の二の舞にはならないように
- 中途半端な機能しかなかった
- メモリリークがひどかった
- イノベーションにAPIは必要なのか?
Greasemonkeyは貧弱なAPIしかないのにあれだけイノベーションが起こった
Jetpackもそのくらいでいいのかもしれない
ドキュメント
- 解説記事が少ない
- アドオン開発者がJetpackをさわるまでのパスを作る。
アドオンではこうやってたところがJetpackではこうなります。
=>むしろ、全然別物として作り始めた方がわかりやすいという現実はある。 - ドキュメント場所に一貫性が無いっつー話
フリーズしたAPIからどんどんMDCに移動して!
Jetpack拡張について
- 内蔵エディタによる開発はめんどくさい
- いちいちタブを切り替える必要がある
- 外部エディタが使えれば問題がない
- エディタおよびインストーラ含め開発効率が悪い
※具体的な案が欲しいっすね
Jetpackギャラリーについて
- 一度「削除」すると、同じ名前ではFeatureを登録できない
=>セキュリティ的には、できなくていいんじゃないか
Twitterで、すでに退会したユーザと同じ名前でアカウントを取り直して乗っ取るということができてしまう。 - AMOでできることはできるように
- レビューシステムによる安全性の担保
- 対応バージョン判別(APIバージョン?)
- セキュアな自動アップデート
Jetpack Featureのパッケージング、インストールおよびアップデートについて
- インストール・アップデートにおけるセキュリティ関連
現状では、新しかったら問答無用でインストールされてしまう。
悪意のある開発者が、無害なFeatureを登録した後アップデートでマルウェアを登録したら、ユーザの環境にそれが勝手に貼ってしまう! - セキュリティのモデル
- マニフェスト
- バージョンアップの仕組み
- 外部スクリプトとの連携
- パッケージ化
画像、HTMLなどをパッケージングして提供できるように。
一つのJSファイルの中に全部置かなきゃ行けないのはつらい。
みらい
- Jetpack の位置づけがあいまいだ
メインになるかならないか。はっきりして欲しい。開発者が本気で取り組めない。 - グリースモンキーとの共存は? 完全に置き換えるの?
- むしろ、GMスクリプトを全く修正なしに動かせるようにしていいのでは?
- そういう意味では Google Chrome 拡張も?
- ユーザがプログラムを書ける時代がやってくるか?
- エディタを賢く
- コード補完
- リファレンス
- ローカライズ
- 国際化
- ビジュアルプログラミングは?
- エディタを賢く
- 外部アプリケーションとの連携(iTunes)って本当に必要か?
- 必要だとしたらどんなAPIが必要か?
- OS化してきているブラウザにとっては、アプリ連携は必須なのかもしれない?
- アドオンでJetpackのAPIを追加できるようにしてほしい
- プロポーサルの方法
プロポーサルを出す文化が日本には無い- バグトラックみたいなシステムがあればやりやすい
- 日本でそういうチームを作る!