― MozillaZine.jp フォーラムは Mozilla 製品に関する情報交換の場です ―



All times are UTC + 9 hours

新しいトピックを投稿する トピックへ返信する  [ 2 件の記事 ] 
作成者 メッセージ
投稿記事Posted: 2013年8月18日(日) 20:14 
 初めまして。私は「本堂」と申します。

 個人的に、Firefoxを使うばかりで貢献はしておりませんのにクレーム同然
の内容ですので、雑談の場所に記させて頂きます。

 二つ思っている事が有り、一つ目ですが「パフォーマンス」と「ヘルス」の
送信に関し、例えば「送信後に何か表示される」等が有ると嬉しいのですが、
この考えはおかしいでしょうか? 個人的には貢献として送ってもよいと感じ
ているのですが、プライバーシーが守られていても「いつ送信されたのかが分
から無い」のが不気味で、そうで無くともせめて「送られた内容」のログを日
本語で参照が出来ますと安心感が…なのです。

 二つ目ですが、総接続数などを最初からRFC準拠にして頂いて「パイプライ
ン処理を使う・使わないを選択するだけ」という方式にするというのは乱暴で
しょうか? RFCを越えた強引な接続でサーバに負担を掛けてFirefoxが嫌われ
てしまうのはよくないと思うのです。

 二つとも非常に我が儘で贅沢すぎるとは思うのですが、せっかくですので他
の方へも伺いたくなり投稿させて頂きます。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2013年8月22日(木) 22:07 
こんにちは、本堂さん。

偶然的通行人と申します。
ぼくは、Mozilla の関係者ではない一介のエンドユーザーに過ぎませんが、
本堂秀雄 さんが書きました:
せっかくですので他
の方へも伺いたくなり投稿させて頂きます。

とのことなので、個人的に考えることを書かせていただきます。

本堂秀雄 さんが書きました:
一つ目ですが「パフォーマンス」と「ヘルス」の
送信に関し、例えば「送信後に何か表示される」等が有ると嬉しいのですが、
この考えはおかしいでしょうか? 個人的には貢献として送ってもよいと感じ
ているのですが、プライバーシーが守られていても「いつ送信されたのかが分
から無い」のが不気味で、そうで無くともせめて「送られた内容」のログを日
本語で参照が出来ますと安心感が…なのです。

ご趣旨には、ぼくも賛成です。

Mozilla が目指しているというところの "人々がすべてを承知している状態" の原則を具現化していく過程には、本堂さんがおっしゃることが含まれていてもいいと思います。
(参考)
http://www.mozilla.jp/blog/entry/10299/

現状では、そこまでできていないかもしれませんが、まずは Mozilla に要望してみればいいのではないでしょうか。
・Firefox のリリースノート
(参考)
http://www.mozilla.jp/firefox/23.0.1/releasenotes/
の冒頭に、「このバージョンの変更点と既知の問題を掲載しています。いつものように フィードバックを提供 するか バグを報告 して、Firefox の改良にご協力ください」とあります。
文字通りの不具合報告や機能の追加や削除に関する具体的な提案は「バグ報告」で対処するのが望ましいですが、一般的な要望は「フィードバックの提供」でも可能です。

本堂秀雄 さんが書きました:
 二つ目ですが、総接続数などを最初からRFC準拠にして頂いて「パイプライ
ン処理を使う・使わないを選択するだけ」という方式にするというのは乱暴で
しょうか? RFCを越えた強引な接続でサーバに負担を掛けてFirefoxが嫌われ
てしまうのはよくないと思うのです。

専門知識のないぼくがいうのもなんですが、理論上の正当性と、現実の進歩や実用性の間に乖離があるのではないでしょうか。
現状の RFC の規定自体、実情に合わないナローバンド時代の古いもの、といった意見はよく耳にします。

回線、サーバ(ハード、ソフト)、クライアント(ハード、ソフト)それぞれの性能が大幅に進歩しているのは事実ですが、ネットワーク接続の常態化やコンテンツ(データ量)の巨大化、ユーザー数の増加、ユーザーの利用形態(例:タブの多用、スマートフォンの普及など)の変化などもありますので、それらのバランスをどう読み解くかが、最適解を導き出すカギなのかもしれませんね。

Firefox の現状での初期値は、最大接続数(network.http.max-connections)が 256 、サーバあたりの持続的最大接続数(network.http.max-persistent-connections-per-server)が 6 です。(パイプラインは初期値では無効)
この初期値がベストかどうか、ぼくには判断できませんが、
(1)初期値を RFC に準じた値にした結果、ブラウザの利用に問題をきたし、その値を変更することになるユーザー数
(2)初期値を現実に即した値にした結果、ブラウザの利用に問題をきたし、その値を変更することになるユーザー数
―― どちらが、どの程度多いかということなのかもしれません。

おそらく、(1)のユーザー数より、(2)のユーザー数のほうがずっと少ない(ゼロではないが)といった判断があり、現在の値になっているのではないでしょうか。(ネットワーク環境の貧弱な地域のユーザーにとっては、不都合が起こりやすいのかもしれませんけど...。)
そして、こうした初期値をどのように定めるかも、ユーザーから送信される「パフォーマンス情報」の統計などをもとに判断されているように思われます。

おっしゃるように、立ち返るべき基準(RFC など)があり、それを意識し尊重することはとても重要だと思います。
同時に、現実の進歩に即して(試験的な意味合いを含め)柔軟に対応していく姿勢もまた、次のステップを切り開く(≒新しい基準を作る)という観点からみると、大切なことだと思います。

どっちつかずな言い方で申し訳ありませんが、専門的な技術が関わるとシロウトの判断には限界がありますので、ご容赦のほどを...。

ユーザー同士の率直な意見交換、という立場で書き込ませていただきました。
失礼な言い回しがあったらごめんなさい。事実に反する間違ったことを述べている点は訂正のツッコミをいただけるとありがたいです。

_________________
Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0


通報する
ページトップ
  
引用付きで返信する  
期間内表示:  ソート  
新しいトピックを投稿する トピックへ返信する  [ 2 件の記事 ] 

All times are UTC + 9 hours


オンラインデータ

このフォーラムを閲覧中のユーザー: Yahoo [Bot] & ゲスト[2人]


トピック投稿:  可
返信投稿:  可
記事編集: 不可
記事削除: 不可
ファイル添付: 不可

検索:
ページ移動:  
Powered by MozillaZine.jp® Forum Software © phpBB Group , Almsamim WYSIWYG
Japanese translation principally by ocean