---

■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 最新50

read.cgi改良スレッド ２

292 ：デフォルトの名無しさん ：01/09/14 13:01

>>291
　現状のchunkは 50レス単位となっているが、これでは多すぎると
感じていたんだが、これを少なくするとchunk一覧が大きくなるという
問題を感じて、こんなもんかと思っていた。

　しかしchunkを一覧せず、前のXX / 次のXX とするなら、一括表示
単位を50より少なくしても何の問題もなくなるわけだね。この点で
この方式を推したい。
　もちろんこの50という数字が多すぎると感じるかどうかは板の性質
によるだろうし、もともとconfigで仮にdefault定義されただけの値だと
いうことは分かるが。

　ということでおおむねその形は良いと思う。
まあ、下には「新レス」も欲しいかな。別の機能ということで書かなかった
だけかもしれんが。

293 ：デフォルトの名無しさん ：01/09/14 13:05

新レスはあってもいいけど名前は変えたほうがいいと思う。
未読とか新着とか。

294 ：125 ：01/09/14 13:06

>>292
「新レス」と「次の50」は機能的にほぼ同じです。
両方つけるのは無駄でしょう。

あと表現（表示文字）についても意見をお願いします。

295 ：292 ：01/09/14 13:13

>>294
ああ、なるほど。確かにほとんど一緒か。

表現は、非混雑事の「1-」は上にあるほうが良くないかな。
というより、どうせなら非混雑時は上下ともに

掲示板に戻る 全部 1- 前50 次50 最新50

みたいにするとか。非混雑時は利便性を落とすほどに帯域を
気にしなくて良いので。

296 ：125 ：01/09/14 13:18

最後まで表示した時は、「次の50」を「未読」にするってのも
読み終わったことが判っていいかな。

297 ：292 ：01/09/14 13:33

　chunk表示はもともとキャッシュヒットさせやすくすることで
帯域削減効果を狙うものだった。
　だがchunk一覧を表示してしまうことにより、最大メッセージ数が
変化すると、末尾chunkでなくともchunk一覧の表示が変化し、結局
cacheが無効になってしまうというジレンマがあったね。

　前/次方式はその点でもキャッシュしやすくなるが、chunk sizeで
割り切れる位置(+1)からスタートする表示をしやすくすることで、
cache効果も狙えるようになるんではないかな。

　たとえば、「前50 / 次50」ならば、現在の地点の前/次にある
50区切りのchunkを表示するようにするとか。
(半端な位置から呼び出した場合重複は起きるが、cacheが
ある程度効くのであれば無視できる)

298 ：292 ：01/09/14 13:44

　297とは別に、従来のchunk方式をcacheしやすく改善する
方向も考えてみる。
　chunk一覧が変化することがcacheの妨げになるのであれば、
これをできるだけ変化しないようにすれば良いことになる。

　そこで、chunk一覧は現在のchunk以前のみにし、後続する
chunkについては「次chunk」「最終chunk」に変更する。

例: 300レスあるが、現在 101-150chunk を表示している場合の
一覧

1- 51- 次50 最終50

　「最終chunk」は、最新レスから50個分さかのぼるのではなく、
最後の50区切り地点以降をあらわす。リンク自体も固定化しない
とcacheされないため、実現にはcgiに新パラメータが必要になる。

　こうすれば、最終よりも前のchunkについては、あぼーんなどが
発生しない限り不変となり、cacheが効果的に期待できるように
なるのではないかと思う。

299 ：292 ：01/09/14 13:49

>>298
まあ、実際には前/次で十分なので、このようなアイデアは
混乱を呼ぶだけか。スマソ。

300 ：デフォルトの名無しさん ：01/09/14 13:50

実際の操作を考えると、上に「最新レス50」がある必要って
あまりないのではと思うのですが．．．
今までとの互換性もあるし、やはりあった方がいいのかな？

301 ： ◆D69Zsbfg ＠夜勤 ★ ：01/09/14 19:16

新スクリプト実験場も作ったので、
今夜あたり　また新しい version の read.cgi を入れてみようかな?
と考えています。　区切りが良かったら教えてください。

いつも　お世話になっています。

302 ：125 ：01/09/14 20:34

上：掲示板に戻る 全部 1- 前50 次50 最新50
下：掲示板に戻る 全部 1- 前50 次50 最新50

混雑時
上：掲示板に戻る 1- 前50 次50 最新50
下：1- 次50 最新50

こんなもんで実装して試してもらいましょうか？

303 ：デフォルトの名無しさん ：01/09/14 21:51

>>302
いいんじゃないすか〜

304 ：125 ：01/09/14 22:36

>>302の機能ができあがりました。
PREV_NEXT_ANCHORとして付け加えました。
ソース的にはまだ不完全ですが、今の組み合わせなら大丈夫なはずです。
（他のconditionとの組み合わせの検証、"前""次"がread.c内に残っている等）

CHUNK_NUM=50,RES_NORMAL=100だと混雑時にちょっと不自然な感じがするような気がします。

305 ：125 ：01/09/14 22:52

誰か他の人がチェックしてOKだったら夜勤さんにお願いといきたいんですが、
他の開発者は今いるのか？

306 ：前レス775 ：01/09/14 22:54

>>305
へーい、試します

307 ：306 ：01/09/14 22:57

>>304
なんか、現在表示中の範囲内のレスへの >> も
新しいウィンドウとして単独表示しちゃってるね。

308 ：306 ：01/09/14 23:03

>>307
ってread2ch.hでCREATE_NAME_ANCHORがコメントアウトされてたからか。
と実験してるうちに23時過ぎてしまったので混雑時モードに変わった(笑)
時刻範囲もいじって両方確認中…

309 ：306 ：01/09/14 23:05

>>304
PATH形式じゃない、従来型で呼び出したときにも
">>"のリンクがPATH形式になっちゃってるね。

310 ：306 ：01/09/14 23:08

>>304
「最新50」した結果に出てくる前50/次50が表示してるレス番号と
全然違う値になってる。

311 ：125 ：01/09/14 23:10

>>307
NAME ANCHORを使うかどうかによるんだけど、
CHUNK_ANCHORとセットじゃないといまいちって話が出てたんです。
（>>207あたり）

NAME ANCHORを使って、表示内へは#で飛ばした方がいいんですかね。
それか、混雑時に内部リンクを切る機能があるはずだから平常でも使うように
するかですね。

上下の各アンカーは変な所はないですか？

312 ：306 ：01/09/14 23:15

>>311

> NAME ANCHORを使って、表示内へは#で飛ばした方がいいんですかね。
> それか、混雑時に内部リンクを切る機能があるはずだから平常でも使うように
> するかですね。
うん、NAME_ANCHOR未定義時は表示範囲内へはリンク切ったほうがいいかも。

> 上下の各アンカーは変な所はないですか？
>>310 がまずいかも。

313 ：125 ：01/09/14 23:17

>>309
えっ。逆じゃないですか？
まだPATHまで対応してません。
>>310
表示している最初のレス番と、前後のリンクの番号を教えてください。

314 ：306 ：01/09/14 23:25

>>313
たとえば
〜/test/read.cgi/tech/998845501/?ls=50
で表示されるヘッダが
次50が &st=100&to=150 になってます。

〜test/read.cgi/tech/998845501/read.cgi?bbs=tech&key=998845501&st=300&to=350
だと、本文中の >> が
〜/test/read.cgi/tech/998845501/299-299
の形式になってたりしてます。

315 ：306 ：01/09/14 23:25

>>314
〜/test/read.cgi/tech/998845501/?ls=50
のとき、手元のデータでは先頭が830になってます。

316 ：125 ：01/09/14 23:36

>>314-315
全部PATH形式で呼び出された後の問題ですね。
確かに変だ。

さて、どうしたものか。
とりあえず、従来形式では大丈夫なのを確認してください。
>>を表示内はカットする

ここまででやっておいて、
夜勤さんが来る前に間に合えばPATHをなおす
ということでどうでしょうか。

317 ：125 ：01/09/14 23:41

>>314-316
ああ、ls=とst=の両方が指定されたときの優先順問題でした。
path形式での出力をサポートすればOKかな。

318 ：306 ：01/09/14 23:41

>>316
> 全部PATH形式で呼び出された後の問題ですね。
あ、ほんとだ。
〜test/read.cgi/tech/998845501/read.cgi?bbs=tech&key=998845501&st=300&to=350
これ、path形式じゃないと思い込んでた。後半しか見てなかった。失礼しました。

319 ：デフォルトの名無しさん ：01/09/14 23:43

個人的には50レスごとのリンクより「50戻る」の方が欲しいっす。

320 ：306 ：01/09/14 23:44

>>319
今試してる「前50」がそれに相当するかな。

321 ：125 ：01/09/15 00:06

NORMAL_TAGCUT として、常に表示内への>>リンクをカット。
ls=とst=が両方指定された時の問題を修正。
これで、PATH呼び出しでも気持ち悪いリンクだけど一応動作する。

これで、いつ夜勤さんがきても大丈夫かな。
じゃPATH形式の出力やってます。

322 ：306 ：01/09/15 00:07

>>321
ほい、2点とも動作確認しました

323 ：夜勤 ★ ：01/09/15 00:45

どでしょ、入れてもいいかな?

324 ：125 ：01/09/15 00:49

>>323
いま、最新版をコミットしましたので、５分ほど待ってから
入れてください。

325 ：125 ：01/09/15 00:51

PREV_NEXT_ANCHORのpath形式出力をサポートした。
相対pathにした「掲示板に戻る」がpath形式の時に正しくなかった。

326 ：夜勤 ★ ：01/09/15 01:30

>>324
うむ? もういいのかな?
だめだったら、言ってください。あせっても、仕方ないので、ペース合わせます。

327 ：125 ：01/09/15 01:33

>>326
どうぞ入れてみてください。

328 ：306 ：01/09/15 01:34

>>326
いいんじゃないすかね(笑)

329 ：125 ：01/09/15 01:35

ちなみに、5分というのはコミットしてからWEBに反映されるまでの時間です。

330 ：夜勤 ★ ：01/09/15 01:41

じゃ　いきまーす、
今日は、スクリプト実験場。 ex.2ch.net に入れますネ。

331 ：306 ：01/09/15 01:48

>>330
お、変わった

332 ：夜勤 ★ ：01/09/15 01:48

入れました。
http://ex.2ch.net/ainotane/

333 ：125 ：01/09/15 01:51

>>332
ご苦労様でした。

うーん。なんと実験に最適な環境なんだ。
mod_gzipが入っていれば完璧なんですけどねぇ。

334 ：名無し娘。 ◆vP.bOZFQ ：01/09/15 01:51

>>332
夜勤さんいつもいろいろおつかれさまですー。
125さんもたくさんたくさんおつかれさまですー。
皆さんもおつかれさまですー。

でも<hr>に<dd>がかかってる。。。気持ち悪いよぉ(泣
# 機能にも転送量にも関係なくてごめん。

335 ：125 ：01/09/15 01:54

>>334
あっ。そ〜お〜いえば〜あ、そ〜いうのがあったなあ。
こめん忘れてた。

336 ：名無し娘。 ◆vP.bOZFQ ：01/09/15 02:00

>>335
ぺこぺこ

「名前：」を「：」にするのは、夜勤さん＆indexをいじれる人的にはどうなのでしょう。
なかなか大きいと思うのですが、index が先行してくれないと、やっちゃいけないのかな
という雰囲気があると思うです。

337 ：夜勤 ★ ：01/09/15 02:01

繁忙期を２時までにしてくるです。

338 ：125 ：01/09/15 02:21

pathの時に>>nnnがnofirst=trueになってないな。

339 ：イラストに騙された名無しさん ：01/09/15 02:42

http://ex.2ch.net/test/read.cgi/ainotane/1000457087/

最後の / を抜かしても同じように表示されますが、
[1-][最新50]などのリンクがおかしくなるので、
フォーマットが間違ってるとかの理由つけて
エラーにしちゃった方がいいかと思います。いかがか？

Location: で正しいURL返してあげる、なんてことは必要ないでしょうから。

340 ：夜勤 ★ ：01/09/15 02:45

read.cgi ver 5.21 入れたのと、ほぼ同時に、転送量が 3倍くらいに
なったんですけど、、、

単に、人が増えただけですかねー?

341 ：306 ：01/09/15 02:50

>>340
gzipはちゃんとかかってるみたいだけどなあ。
前50 次50 方式は逆効果だった? (^^;
使いやすくなってサクサク開いちゃってるとか(笑)

342 ： ：01/09/15 02:58

皆様お疲れ様です．

実験場で，レス 1 と 204-252 が表示されている状態，10241 バイトなんですが，
これに css を使う（<font color=green></font> を消す）と 670 バイト減らせます．
こういうのって，すでに意味がなくなってるんでしたっけ？お邪魔だったらすみません．

343 ：125 ：01/09/15 02:59

>>340
人が増えて＋ものめずらしさであっちこっちクリックして、じゃないかと。

cgiの変更で増える要因は「全部」だけのはずです。
落ち着けば、その分は他の機能が相殺してくれると踏んでるんですが。

転送量の評価には、ある程度安定したアクセスのサーバーじゃないと
無理でしょうね。
あそこは、復活して間も無いし。

344 ：125 ：01/09/15 03:05

全部 1-　→　全 最初から読む

こんな風に変更したら、「最初から読む」の方を使ってくれないかな。
途中まで読んで、もういいやってことも良くあるし。

345 ：342 ：01/09/15 03:06

定量的には
css の宣言で +122 バイト
<font...> で -25x（メール欄のない発言数）バイト
です．

346 ：名無し娘。 ◆vP.bOZFQ ：01/09/15 03:06

>>340
ふが。。。
なぜだろう。。。>>343 の通りでありますように。。。

347 ：デフォルトの名無しさん ：01/09/15 03:11

単に「全部読む」がクリックされまくっているのでは(index.htmlからも含)？
時間制限はずしてあったし。

348 ：125 ：01/09/15 03:20

下にある「掲示板に戻る」は便利過ぎるかも。
読み終わって、即戻れるとindex.htmlのアクセス数が増えそう。

349 ：デフォルトの名無しさん ：01/09/15 03:22

ところで125さん、cvsにtag打っといてくれますか〜
YAKIN20010915かな。

350 ：125 ：01/09/15 03:26

>>349
へい、打っときました。

351 ：名無し娘。 ◆vP.bOZFQ ：01/09/15 12:32

要望板からこのような報告が。
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=998808733&st=833&to=833&nofirst=true

確認したところ、確かに10番目の発言を取りこぼしています。
びっくりしました（＾＾；

352 ：デフォルトの名無しさん ：01/09/15 12:35

がいしゅつかつ修正済みです。 >>247-250

353 ：名無し娘。 ◆vP.bOZFQ ：01/09/15 12:46

>>352
あ、NULLだということは＆修正は認識していたのですが、version違いを忘れてました（＾＾；
すいませんです。

354 ：125 ：01/09/15 14:30

下に便利さのための機能は、置かない方がいい気がしています。

本当にその機能を必要とする人は、上まで戻ってでも使うでしょう。
そうでない人には、余計な選択肢は出さない方がいいかと。

下に置くものは、「次50／未読」だけがいいんじゃないかな。
「最新50」で読みたい人でも手近に「未読」しかなければ、かなりの人が
未読でがまんしてくれると思います。

355 ：デフォルトの名無しさん ：01/09/15 14:43

>>354
注意すべきは混雑時だけですよね?

356 ：デフォルトの名無しさん ：01/09/15 18:32

main()をちょっといじるだけで、他の部分へ影響しないようにできたので、>>244を実装してみた。
混雑時に>>nnをクリックした時に、FORM等が出なくなる。
圧縮すらしてない、ただのテキスト。

W3JlYWQyY2guaF0KLyogjayOR46eitSR0YLJgUE+Pm5ujGCOroLMg4qDk4NOgqmC545Rj8aC
s4Lqgr2P6o2HgskKICAgj2+XzWh0bWyCqYLnl12VqoLIg4qDk4NOk5mC8I/Igq0gKi8KLyoj
ZGVmaW5lCVJFRkVSRFJFU19TSU1QTEUqLwoKW3IyY2hodG1sLmhdClIyQ0hfSFRNTF9IRUFE
RVJfMSCCzI78ldMKI2RlZmluZSBSMkNIX1NJTVBMRV9IVE1MX0hFQURFUl8xKHRpdGxlKSBc
CgkiPGh0bWw+IiBcCgkiPGhlYWQ+IiBcCgkiPG1ldGEgaHR0cC1lcXVpdj1cIkNvbnRlbnQt
VHlwZVwiIGNvbnRlbnQ9XCJ0ZXh0L2h0bWw7IGNoYXJzZXQ9U2hpZnRfSklTXCI+IiBcCgki
PHRpdGxlPiIgdGl0bGUgIiA8L3RpdGxlPiIgXAoJIjwvaGVhZD4iIFwKCSI8Ym9keSBiZ2Nv
bG9yPSNlZmVmZWYgdGV4dD1ibGFjayBsaW5rPWJsdWUgYWxpbms9cmVkIHZsaW5rPSM2NjAw
OTk+IgoKW3JlYWQuY10KbWFpbigpgsyBQWRhdF9yZWFkKCk7IILMgreCrozjgsmBQQojaWZk
ZWYJUkVGRVJEUkVTX1NJTVBMRQoJaWYgKGNhbl9zaW1wbGVodG1sKCkpIHsKCQlvdXRfc2lt
cGxlaHRtbCgpOwoJCXJldHVybiAwOwoJfQojZW5kaWYKCoLHgrGCqYLJCiNpZmRlZglSRUZF
UkRSRVNfU0lNUExFCmludCBjYW5fc2ltcGxlaHRtbCgpCnsKCWNoYXIgYnVmZlsxMDI0XTsK
CWNvbnN0IGNoYXIgKnA7Cgljb25zdCBjaGFyICpyZWY7CglzdGF0aWMgY29uc3QgY2hhciBj
Z2luYW1lW10gPSAiL3Rlc3QvIiBDR0lOQU1FICI/IjsKCXN0YXRpYyBjb25zdCBjaGFyIGlu
ZGV4bmFtZVtdID0gImluZGV4Lmh0bSI7CgkKCWlmICghaXNidXN5dGltZSkKCQlyZXR1cm4g
ZmFsc2U7CglpZiAoIW5uX3N0IHx8ICFubl90byB8fCBpc19pbW9kZSgpKQoJCXJldHVybiBm
YWxzZTsKCWlmIChubl9zdCA+IG5uX3RvIHx8IG5uX3RvID4gbGluZU1heCkKCQlyZXR1cm4g
ZmFsc2U7CgkvKiCCxoLogqCCpoK4gUGDioOTg06Q5oLMg4yDWIKqglCCwoLMj+qNh4K+gq8g
Ki8KCWlmIChubl9zdCAhPSBubl90byB8fCAhaXNfbm9maXJzdCgpKQoJCXJldHVybiBmYWxz
ZTsKCS8qaWYgKCEobm5fc3QgKyAxMCA8PSBubl90bykpCgkJcmV0dXJuIGZhbHNlOyAqLwoJ
cmVmID0gZ2V0ZW52KCJIVFRQX1JFRkVSRVIiKTsKCWlmICghcmVmIHx8ICEqcmVmKQoJCXJl
dHVybiBmYWxzZTsKCQoJc3ByaW50ZihidWZmLCAiLyUuNTBzLyIsIHp6X2JzKTsKCXAgPSBz
dHJzdHIocmVmLCBidWZmKTsKCWlmIChwKSB7CgkJaW50IG4gPSBzdHJsZW4oYnVmZik7CgkJ
aWYgKCoocCArIG4pID09ICdcMCcpCgkJCXJldHVybiB0cnVlOwoJCWlmIChzdHJuY21wKHAg
KyBuLCBpbmRleG5hbWUsIHNpemVvZihpbmRleG5hbWUpLTEpID09IDApCgkJCXJldHVybiB0
cnVlOwoJfQoJcCA9IHN0cnN0cihyZWYsIGNnaW5hbWUpOwoJaWYgKHApIHsKCQljaGFyIGJi
c1tzaXplb2YoenpfYnMpXTsKCQljaGFyIGtleVtzaXplb2Yoenpfa3kpXTsKCQljb25zdCBj
aGFyICp0bXAgPSB6el9xdWVyeV9zdHJpbmc7CgkJenpfcXVlcnlfc3RyaW5nID0gcCArIHNp
emVvZihjZ2luYW1lKS0xOwoJCXp6X0dldFN0cmluZyhiYnMsIHNpemVvZihiYnMpLCAiYmJz
Iik7CgkJenpfR2V0U3RyaW5nKGtleSwgc2l6ZW9mKGtleSksICJrZXkiKTsKCQl6el9xdWVy
eV9zdHJpbmcgPSB0bXA7CgkJcmV0dXJuIHN0cmNtcCh6el9icywgYmJzKSA9PSAwICYmIHN0
cmNtcCh6el9reSwga2V5KSA9PSAwOwoJfQojaWZkZWYJVVNFX1BBVEgKCXNwcmludGYoYnVm
ZiwgIi90ZXN0LyIgQ0dJTkFNRSAiLyUuNTBzLyUuNTBzLyIsIHp6X2JzLCB6el9reSk7Cglp
ZiAoc3Ryc3RyKHJlZiwgYnVmZikpCgkJcmV0dXJuIHRydWU7CiNlbmRpZgoJcmV0dXJuIGZh
bHNlOwp9CgppbnQgb3V0X3NpbXBsZWh0bWwoKQp7CgljaGFyICpzWzIwXTsKCWNoYXIgcFtT
SVpFX0JVRl07CglpbnQgbiA9IG5uX3N0OwoJCgkvKiBodG1sX2hlYWQoKSAqLwoJc3BsaXR0
aW5nX2NvcHkocywgcCwgQmlnTGluZVswXSwgc2l6ZW9mKHApIC0gMjAsIDApOwoJaWYgKCEq
cCkKCQlyZXR1cm4gMTsKCXBQcmludGYocFN0ZG91dCwgUjJDSF9TSU1QTEVfSFRNTF9IRUFE
RVJfMSgiJXMiKSwgc1s0XSk7CglwUHJpbnRmKHBTdGRvdXQsIFIyQ0hfSFRNTF9IRUFERVJf
Miwgc1s0XSk7CgkKCW91dF9yZXNOKys7CS8qIIN3g2KDX49vl82C8Jd9jn4gKi8KCWlmICgh
aXNfbm9maXJzdCgpKSB7CgkJb3V0X2h0bWwoMCwgMCwgMSk7CgkJaWYgKG4gPT0gMSkKCQkJ
bisrOwoJfQoJZm9yICggOyBuIDw9IG5uX3RvOyArK24pIHsKCQlvdXRfaHRtbCgwLCBuLTEs
IG4pOwoJfQoJCgkvKiBodG1sX2Zvb3QoKSAqLwoJcFByaW50ZihwU3Rkb3V0LCBSMkNIX0hU
TUxfRk9PVEVSKTsKCXJldHVybiAwOwp9CiNlbmRpZgkvKiBSRUZFUkRSRVNfU0lNUExFICov
Cg==

357 ：デフォルトの名無しさん ：01/09/15 23:19

>>266のサイズ出力を加えて、dat_out_raw()を整理したよ。
getlinelenは消していいね。

int dat_out_raw(void)
{
　const char *begin = BigLine[0];
　const char *end = BigLine[lineMax];
　/* ・・・ */
　if(raw_lastnum > 0
　　&& raw_lastsize >= 0
　　&& !(raw_lastnum <= lineMax
　　 && BigLine[raw_lastnum] - BigBuffer == raw_lastsize)) {
　　pPrintf(pStdout, "-INCR");
　　/* 全部を送信するように変更 */
　} else {
　　pPrintf(pStdout, "+OK");
　　/* 差分送信用に先頭を設定 */
　　begin = BigLine[raw_lastnum];
　}
　pPrintf(pStdout, " %d\n", end - begin);
　/* raw_lastnum から全部を送信する */
#ifdef ZLIB
　if (gzip_flag)
　　gzwrite(pStdout, (const voidp)begin, end - begin);
　else
#endif
　　fwrite(begin, 1, end - begin, pStdout);

　return 1;
}

358 ：デフォルトの名無しさん ：01/09/15 23:28

>>357
あてた

359 ：デフォルトの名無しさん ：01/09/16 02:01

NORMAL_TAGCUTなんかいらねーよ。
通常時間帯の使い勝手を悪くするのは、ただの「改悪」だろ。
「レスを全部読む」の件をもう忘れたらしいな。

360 ：デフォルトの名無しさん ：01/09/16 02:29

>>359
忘れたも何も、「レスを全部読む」の件はお前が知らないだけ。
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=998808733&st=906&to=906

361 ：デフォルトの名無しさん ：01/09/16 02:37

>>359
要らないかどうかを判断するのはお前ではない。ましてや開発者でもない。
このスレは与えられた命題に対する回答を提案するためのもので、実際に
導入するかどうかは運営側に委ねられている。

362 ：125 ：01/09/16 03:53

>>359
NORMAL_TAGCUTを見つけるぐらいちゃんと見てるわりに、ここの趣旨が
理解できてないな。

作って見る→あんまり良くない→OFF推奨でプログラムには残す。
一度作ったものは、そう簡単になくしはしない。
改悪にしか思えなくても転送量が減るなら試すのがここのやり方だ。

何のために簡単にON/OFFできるように作ってると思ってるんだ。
おまえが言うべき言葉は「NORMAL_TAGCUTはOFFにしとけ」だ。
否定的意見は歓迎するが、全否定は言うだけ無駄だぞ。

まあ、NORMAL_TAGCUTはOFFにしとくかな。

それと言い方変えると採用されやすいぞ（藁
「通常時間帯までTAGCUTしないでいいんじゃないの。」
「そうでした。じゃ、NORMAL_TAGCUTはoffにしておきます。」
それでも運営側がONにするかもしれんがな。

363 ：359 ：01/09/16 14:23

>>360-362
どうやら、俺を誰か他の人間と勘違いしているらしいな。
一応俺もそれなりの量のコードは書いて、反映されているんだがな。
例えば>>357とか。
過去の要望や修正で忘れられているものを直しながら読み進め、
動作を確かめるのが遅れたから、今更言ったわけだが。

>>361
それには当然目を通しているが、俺の認識では
「全部読む」がなくなったのはCHUNK_ANCHORを優先させるために
ただ入れ忘れただけだと思っていたが。
もちろん、「混雑時なら」実験としても意味があると思うし、
そこには書いてないが、コピペしてst=やls=を外せばいいだけだから、
混雑時に(どうせ100しか読めない)「全部読む」が無くなっても
大きな問題だとは、俺も思わない。

>>362
例えば、>>276なども俺なのだが。

>要らないかどうかを判断するのはお前ではない。ましてや開発者でもない。
俺も開発者であり、利用者でもある。

>このスレは与えられた命題に
ピーク時の転送量削減と、負荷の低減が与えられた命題。
混雑時以外は、できるだけ要望に沿った機能にすべきだと思っている。
サイズが大きすぎになる前に警告を出すとか、ね。

>回答を提案するためのもので、
俺は、開発者の１人として、運営者に提案したくないと思ったから、
ああ書いた。俺以外が皆賛成なら、仕方ないが。

>実際に導入するかどうかは運営側に委ねられている。
だから、実際に本格導入される前に意見を述べている。

364 ：359 ：01/09/16 14:24

>>363
>NORMAL_TAGCUTを見つけるぐらいちゃんと見てるわりに、
ほぼ全て把握しているつもりだけど？

>ここの趣旨が理解できてないな。
それは申し訳なかったね。

>一度作ったものは、そう簡単になくしはしない。
INDEXはどうした？COOKIEは？
それに、「OFF推奨」が試験導入に際しては意味が無く、
read2ch.hでのdefineがそのまま残ることは、
今までの動きから明らかだろ。
それが本格導入ではないとしても、数日から数週間の間、
試験導入されたサーバーの住民から見れば、
「完全に変更された」ように見えるわけだ。

>おまえが言うべき言葉は「NORMAL_TAGCUTはOFFにしとけ」だ。
いや、違うね。
「ピーク時の転送量と負荷という主命題を忘れるな」だ。
「自己満足になってないか？」もね。
あらかじめ言っておくが、key=xxxxだけでls=50になるとかも、俺は反対だよ。
NORMAL_TAGCUTは要望もなく、同意も求めていないように見えたが。
俺は、「ピーク時」が全てだ今でも思っているからね。

>それと言い方変えると採用されやすいぞ（藁
そいつは悪かったな。
俺は２ちゃんの良さは、「発言者」「言葉遣い」ではなく、
「発言内容」のみで評価されることにあると思っていたからな。
言い方は、その時の気分で豹変しちゃうんだよ。
「丁寧な言葉遣いで煽り」より、
「乱暴な言葉遣いだが正論」な、
茶羽的な方針でいたいね。
ま、「丁寧な言葉遣いで正論」が一番だろうけどな。

365 ：359 ：01/09/16 14:25

さてと。
>>360-362さんは著しく気分を害されたでしょうし、
俺も、世話になっている人達に文句を言うだけというのは
本意ではないので、
うざいでしょうけど、少々考えを述べたいと思います。

まず、俺を含んでCVSを触らない人間が
修正や変更をした部分をCVSに反映してくれている方々には、
本当に感謝しています。
(特に前スレの775さんには本当にお世話になりました)
ありがとうございます。

本来なら、自分でCVSに触れる方が他の人の手を煩わせずに済むのですが、
逆に自分で触れない場合は、必ず自分以外の誰かの評価(同意)の上で
修正が施されることになるわけで、
自分で見落としていた観点からの評価や、機能自身に対する評価等も
ある程度行われ、同時に不具合を発見してもらえる場合すらあります。
そんな事から、俺個人の意見としては、
「常に他の誰かにやってもらう」のは悪い事ではなく、
むしろ好ましいとさえ思うようになっています。

また、「誰でも簡単にできること」でも、思いつくまま
書きこむようにしていますが、これは邪魔でしょうか？
例えば報告された簡単な不具合の修正個所や、夜勤さんからの要望等でも、
だれも書きこんでいなければ書きこむようにしていますが、
これも、書き込む人と修正する人の２人が目を通すことで
「ちょっとしたミスを避けられれば」との考えからです。
修正する人が注意深く変更してくれるのなら
(不具合報告等の見落としがなければ)必要ないとも考えています。

366 ：359 ：01/09/16 14:25

ところで、「常に他の誰かにやってもらう」とした場合、
修正が数行で済む時はここに書きこむとして、ある程度変更点が大きい時は
CVSを触る人にとってどのようにすれば作業が楽になりますか？
考えつくのは、
・変更個所と変更・追加を示した部分をftp://210.170.xx.xx/incoming/に置く
・diffを取り、ftp://210.170.xx.xx/incoming/に置く
ぐらいですが(なんかまた変わったっぽい)。
こちらで可能な範囲で楽な方法にしたいと考えていますので、
(「自分でやれ」というのはナシで)
できれば希望する方法を書いてもらえると助かります。
(上のftpが使えない時は圧縮してBase64でエンコードして貼ればいいですか？)

最後にもうひとつ。
read.cgiに求められているのは、
「ピーク時の転送量と負荷の低減」でよろしいでしょうか？
現在はまだ実験中ということで、
いろいろ試したい機能もでてくるかと思います。
前スレの734あたりにちらっと書きましたが、実験の方針として、
「転送量削減が見こめるが、使い勝手を損なう可能性がある」
ものは、「試験的に混雑時のみ実施」、
「利便性を向上させるが、転送量を増大させる可能性がある」
ものは、「試験的に非混雑時のみ実施」
という形がbestではないかと思います。
そのために、不必要(かもしれない)な時間帯による場合分けや
外部ファイルによる設定変更等の追加が求められるとしても、
試行錯誤している段階では、できるだけそのようにコードを作るのが
理想ではないかと思っています。いかがでしょうか。

367 ：|　 - -) ：01/09/16 15:19

> CVSを触る人にとってどのようにすれば作業が楽になりますか？

私の場合、になりますが。
diff (ただし-c または -u付きで)を取ってもらうと patch → cvs ci だけで
作業が終わるので楽です。patch にすることで他人の修正内容が上書きされて消
される、という可能性もなくなりますし。
しかしながら、本当は cvs を使ってもらった方がいいのですけど。変な修正が
施されてもどうせ元に戻せるので...。

あ、あとどこかで「"新レスの表示"はどこ?」とか言われていましたね。私も
ちょっと見てどれが「新レスの表示」なのか分からなかったのでできるだけ「未
読」は目立つように太字にするなりもうちょっと表現を改めるなりした方がい
いかと思います。
# わざわざバイト数増やしてどうすんだという声もあるかもしれないけど見つけ
# られずに使われないよりかはマシだと思う

368 ：125 ：01/09/16 16:10

>>363-364
>「レスを全部読む」の件をもう忘れたらしいな。
これで、他の誰かと勘違いした。スマソ。

NORMAL_TAGCUTは、言われて見ればそのとおりかなと思ったが、
開発やめろとしか言わない誰かさんだと思ってああいう書き方をした。
ソースからなくすのは、ある程度の合意か、cvs触っているやつの独断が
必要だ。
（INDEXはまだ完全にはなくなってないよ。COOKIEは使用上の弊害が認め
られたので削除された。）

>>365-366
変更部分を確認するなら手間が少ないんだが、確認しながら変更するのは
かなり手間がいる。
「動作するところまでは確認したから、変更部分に問題ないか確認して
commitしてね。」で、read.cそのものか、diffを渡すのが手間が少なく
ていいかな。
（個人的にはreac.cそのものがいいが）

>「ピーク時の転送量と負荷の低減」でよろしいでしょうか？
「ピーク時の」って所をすぐ忘れるんだよなあ。

>>367
表現の変更で転送量に望ましい選択をしてもらえるならいいんじゃない。

369 ：125 ：01/09/16 17:02

上に「次50」があるのはよくない気がしてきました。
「次、次、次、あっ、ここから読もう。」があまりにも便利。

ということで、再び、上下に置くものについてのご意見をお願いします。

ver5.21の現状
上：■掲示板に戻る■ 全部 1- 前50 次50 最新50
下：掲示板に戻る 全部 1- 前50 [次50/未読］ 最新50
混雑時
上：■掲示板に戻る■ 1- 前50 次50 最新50
下：1- [次50/未読］ 最新50

これを

上：■掲示板に戻る■ 全部 最初から 前50 次50 最新50
下：掲示板に戻る 全部 最初から 前50 [次50/<b>未読</b>] 最新50
混雑時
上：■掲示板に戻る■ 最初から 前50 最新50
下：[次50/<b>未読</b>］ 最新50

こんな感じかな。
混雑時は、下の最新50も取って未読を最優先にしたい所。

＃「前、前、前」ってパターンもあるな。
＃それでも「全部読む」よりはましか。
＃CHUNK_ANCHORがベストな気がしてきた。

370 ：デフォルトの名無しさん ：01/09/16 17:57

＞混雑時は、下の最新50も取って未読を最優先にしたい所。
これ賛成。
それと、5.20の「新レス」(「新着」「未読」かはともかく)の見かけは、
結構好評で、悪評は少なかったように思う。

そこで、平常時を２段式にして、下半分だけのイメージを書いてみる。
続きがのある/なしで最新50が上段/下段となるのが面倒くさいけど、
こんなイメージはどうかな？(表示される文字は適当)

平常時・続きあり
――――――――――――――――――――――――――――
　　　　　　続きを読む　　　　　最新50
――――――――――――――――――――――――――――
　掲示板に戻る 全部読む 1-50
――――――――――――――――――――――――――――

平常時・最後まで読んだ
――――――――――――――――――――――――――――
　　　　　　追加レス
――――――――――――――――――――――――――――
　掲示板に戻る 全部読む 1-50 最新50
――――――――――――――――――――――――――――

混雑時・続きあり
――――――――――――――――――――――――――――
　　　　　　続きを読む　　　　　最新50
――――――――――――――――――――――――――――

混雑時・最後まで読んだ
――――――――――――――――――――――――――――
　　　　　　追加レス
――――――――――――――――――――――――――――

371 ：370 ：01/09/16 18:03

平常時の最新50をつける位置が逆だった。
続きがある時につけなくちゃだめだね。
両方につけてもいいけど。

372 ：370 ：01/09/16 18:07

いや、371が間違いだった。
ちゃんと最新50は上段についてる。
自分でも間違えるくらいだから、使いにくいか。

373 ：125 ：01/09/16 18:42

CHUNK方式が最も効率よさそうなんで、少し考えてみました。
混雑時の100レス制限との噛み合わせを考えて、CHUNKは100単位。

上：■掲示板に戻る■ 全部 CHUNK_ANCHOR 最新50
下：[続きを読む/新着レス]///掲示板に戻る 全部 前100 次100 最新50
混雑時
上：■掲示板に戻る■ CHUNK_ANCHOR 最新50
下：[続きを読む 最新50/新着レス]

※混雑時は表示内への>>リンクははずす。
※続きを読む/新着レスは、最後まで一気読み。

374 ：125 ：01/09/16 22:30

意見くれage

375 ：名無し娘。 ◆vP.bOZFQ ：01/09/16 23:14

>>373-374
混雑時間帯には「続きを読む」に100レス制限つくんですよね？

平常時について「続きを読む」「次100」「最新50」がなんかかぶってるような気が
するんだけど、どれかをなくすとしっくりいかなく、迷っております。

混雑時間帯は
上：■掲示板に戻る■ CHUNK_ANCHOR 最新50
下：続きを読む 最新50
でOKだと思います。

376 ：125 ：01/09/16 23:57

>>375
混雑時100レス制限はそのままです。
平常時の「次100」は、見た目の都合ということで。
害はなさそうですから。

上下のアンカーは、nofirst=trueにしないでいいんですよね。
転送量的には、nofirst=trueですけど。

上に前／次よりもCHUNK_ANCHORを推奨ってことで実装してみます。

377 ：名無し娘。 ◆vP.bOZFQ ：01/09/17 00:12

>>376
はい。いいと思います。

378 ：名無し娘。 ◆vP.bOZFQ ：01/09/17 00:49

実装・検討待ちの案一覧

ETag
　>>137 >>143 >>167-169 >>173 >>229-232

HEADリクエストに対しては Last-Modified と Content-Length を吐くだけにする
　>>219 >>226

URL記述に対するリンク設定も時間帯によらせる
　http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1000035521&st=817&to=817&nofirst=true

「名前：」も「：」だけにする

</dl>するタイミング
　>>126

#define Katjusha_Beta_kisei されていない（元はdefineされていた）

dat,temp,kako
　dat,temp,kako を read.cgi で読む
　　>>203-206 >>208
　datの一部についてのLastModを求める
　ツール作者さんに対応お願い
　　* raw=xxx.yyy の形式でリクエスト。 xxx=最終レス番号, yyy=そのときのサイズ。
　　* 一行目はステータス:
　　* [+OK zzz] の場合は差分のみを送信する。zzzは差分サイズ。
　　* [-INCR] (Incorrect)の場合はすべてのデータを送信する。
　　* [-ERR (テキスト)]の場合はなんかエラーが起きた。

condition一覧/SETTING_R.TXT記述一覧
　http://www.gedoh.org/aki/2ch/current/bbs/config.txt
　追加すべきもの
　　CAUTION_FILESIZE xx, MAX_FILESIZE_BUSY (xx)（デバッグ用）
　　SEPARATE_CHUNK_ANCHOR（CHUNK_ANCHORが必要）, CHUNKED_ANCHOR_WITH_FORM（CHUNK_ANCHOR定義時にのみ有効）
　　　>>189-190
　　CM_BBSPINK, LOGLOGOUT x, TYPE_TERI, Katjusha_Beta_kisei
　　RAWOUT
　　　rawmode時に圧縮対応していないと弾かれる

mmap時にlockすべきか
　http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1000035521&st=139&to=139&nofirst=true
　http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1000035521&st=425&to=425&nofirst=true

FORCE_304_TIME を鯖負荷に応じて動的に変更する

deflate
　そのうち対応

379 ：デフォルトの名無しさん ：01/09/17 01:00

すみません
>342=>345 は検討さえしていただけないのでしょうか…

380 ：名無し娘。 ◆vP.bOZFQ ：01/09/17 01:07

>>379
失礼しました。見落としです。ぺこぺこ。
CSSによる軽量化ですね。
HTML文法にあるCSS宣言ならいいと思います。
# 意味不明かな...HTMLには無くてCSSにだけある定義使うとブラウザがまだ
# 対応し切れていないような気がしたので...ということ。

381 ：379 ：01/09/17 01:33

>380
ありがとうございます．WEB 制作板の方の話はすっかり止まってしまっているので
こちらに直接書き込ませていただきました．

追加されるのは以下の文字列：
</title> の直前に
<meta http-equiv=Content-Style-Type content="text/css">
</script> の直後に
</script><style type="text/css"><!--b{color:green}a b{color:blue}--></style>

削除するのは <font color=green> と，対の </font> です．

>345 にも書きましたが +122-(25*age 発言) バイト減ります．
表示は NN4.78（Win) でも大丈夫なので，ほとんどのブラウザで大丈夫だと思います．

382 ：|　 - -) ：01/09/17 01:41

>>378
#define Katjusha_Beta_kisei と config.txt の書き換えはやりました。

383 ：デフォルトの名無しさん ：01/09/17 01:57

>>378

></dl>するタイミング
>　>>126
出力サイズの小さい、後半であてました

384 ：デフォルトの名無しさん ：01/09/17 02:00

>>378
>>189-190はconfig.txt見るとすでに反映されてますね。

385 ：デフォルトの名無しさん ：01/09/17 02:44

>>378
>「名前：」も「：」だけにする
CUT_NAME_STRINGとして追加しときました。

386 ：デフォルトの名無しさん ：01/09/17 02:56

>>378
>　　* [+OK zzz] の場合は差分のみを送信する。zzzは差分サイズ。
>　　* [-INCR] (Incorrect)の場合はすべてのデータを送信する。
INCRのときも、[-INCR zzz]という形になってるよ。サイズがついてる。

387 ：デフォルトの名無しさん ：01/09/17 03:46

>>378
>HEADリクエストに対しては Last-Modified と Content-Length を吐くだけにする
>　>>219 >>226
これやってみた。

ZLIB時:
　HEADに対してはヘッダのみ出力する。内部的には全部圧縮して、結果の
Content-Lengthも出力。

GZIP時:
　本文も出力しているまま。

無圧縮時:
　通常のヘッダ出力後即終了。Content-Lengthは従来同様出力していない。

388 ：125 ：01/09/17 04:05

PREV_NEXT_ANCHORと同時にCHUNK_ANCHOR/RELOADLINKを指定した時、

上：■掲示板に戻る■ 全部 CHUNK_ANCHOR 最新50
下：[続きを読む/新着レス]///掲示板に戻る 全部 前100 次100 最新50
混雑時
上：■掲示板に戻る■ CHUNK_ANCHOR 最新50
下：[次100 最新50/新着レス]

の形にした。
config.txtの内容をチェックして、ダブりと現状に合っていないものを修正。
PREV_NEXT_ANCHORで使用している文字列をr2chhtml.hに追い出した。
>>のリンクがno_first=trueになっていなかった。

389 ：125 ：01/09/17 04:32

>>381
USE_CSSとして付けた。
一応ONにしておいた。
が、私は普段CSSはoffしてるので、ちょっとだけ悲しい。

＃まずい、寝なきゃ。

390 ：デフォルトの名無しさん ：01/09/17 05:07

>>356
これ適用してみた。

391 ：デフォルトの名無しさん ：01/09/17 06:23

>>387
内部的に圧縮を行ったりgzipを呼んだりしてしまうと負荷が
ほとんど下がらないのでContent-Lengthは出力しなくて
いいと思います。

326KB

---

新着レスの表示

---

スレッドリストへ戻る 全部 前100 次100 最新50

0ch BBS 2004-10-30