---

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

read.cgi改良スレッド ２

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は出力しなくて
いいと思います。

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

>>391
sousitemita.

393 ：デフォルトの名無しさん ：01/09/17 15:58

>IEはヘッダにはAccept-Encoding: gzip, deflateと含めているにも
>関わらず、実際にdeflateでエンコードしたデータを喰わせても
>解釈できないです。

根拠はここ。
http://cvs.m17n.org/~akr/diary/d2001_01.html
ちなみにこの日記自体がContent-Encoding: deflate
で圧縮されているので尋常な手段では読めません。

一言でまとめると、HTTP仕様はzlibフォーマットのdeflateを
要求しているにもかかわらず、IEやNetscape6はzlibヘッダ
の付いていない生のdeflateストリームでないとデコード
できません。
というわけで事実上Content-Encoding: deflateは使えないです。

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

cvsにChangeLogファイル作ってみたよ。
今までの変更のサマリーとtagごとの採用状況をざっと書いてみました。

395 ：369 ◆3XTuRnAc ：01/09/17 23:30

新しいアドレスは、

ftp://10.170.136.232/incoming/

です。IP変わったのは15日の23時ちょっと前の模様。

396 ：369 ◆3XTuRnAc ：01/09/17 23:44

あ、ちょうどいい機会なんで、dyndns取りました。

ftp://readcgi.dyndns.org/

ってことで。

あとはこれを自動更新(せめて一時間に一度程度の自動更新)
ができると良いんですが・・・。

なんとか、一日に一度はチェックするようにしたいと思います。

397 ：名無し娘。 ◆vP.bOZFQ ：01/09/17 23:55

みなさまお疲れさまです。

★CVS使わない人は ftp://readcgi.dyndns.org/incoming/ をご利用下さい

★condition一覧/SETTING_R.TXT記述一覧 変更したら随時更新してね♪
　http://www.gedoh.org/aki/2ch/current/bbs/config.txt


実装・検討待ちの案一覧 @396

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

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

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

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
　そのうち対応（実用困難らしい >>393）

398 ：369 ◆3XTuRnAc ：01/09/17 23:58

たびたびすみません(^^;;。
369ってのは、ここのスレッドの番号じゃなくて、以前の騒動の時の
コテハンでして・・・。

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

>>397
実は>>378もそうなんだけど、リンクされているスレが３つとも、
前スレじゃなくて、このスレだったりして。

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

>>398
おひさしぶりです。
>>399
.....鬱氏(^^;
1000035521 -> 998997848

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

>>397
>★CVS使わない人は ftp://readcgi.dyndns.org/incoming/ をご利用下さい
どちらかというと新たにcvsを使いたい人は、ですね（笑）

402 ：デフォルトの名無しさん ：01/09/18 01:31

>>397

>/tech/998997848/817
>・URL記述に対するリンク設定も時間帯によらせる NO_LINK_URL_BUSY
やっときました。

403 ：anony ◆3XTuRnAc ：01/09/18 02:03

ちょっと要望なんですが、

■掲示板に戻る■ 1- 51- 101- 151- 201- 251- 301- 351- 401- 最新レス50

これ、上じゃなくて下においていただけないですかね。
特に「1- 51- ・・・」の部分。
いったん流し読みして、次を読むためにもう一度一番上までスクロールさせて・・・
ってのはちょっと面倒(^^;;。

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

>>403
下に 前100 次100 と付く予定ですが、それじゃ駄目ですか？

405 ：anony ◆3XTuRnAc ：01/09/18 02:28

>>404
あ、そういう予定があるならそのほうがいいな。

この5.20の書式で行くのかなーと誤解してしまい。
申し訳ない。

406 ：デフォルトの名無しさん ：01/09/18 05:53

mmap時のlockは　どちらにしても読み出し側単独では不可能（というかナンセンス）で
書き込み側での対応が必要かと

407 ：デフォルトの名無しさん ：01/09/18 07:09

んーっと、とりあえず、ETag実装してみた。
知識が足りないので、これでいいのかもよくわからない。
足りない点や見落としなど含め、意見求む。
大幅に書きなおしてくれる人も歓迎。

動作は、まず当初の目的を考えたので、
to=nnが指定されている時だけETagを出力するようにした。
main()の流れは、こんな感じ。
・・LastModifiedチェックの後、atexitを登録してから、
#ifdefPUT_ETAG
　if (need_etag(st, to, ls)) {
　　char etag[60];
　　dat_read(fname, st, to, ls);
　　create_etag(etag);
　　if (match_etag(etag)) {
　　　puts("Status: 304 Not Modified\n");
　　　return 0;
　　}
　　printf("ETag: %s\n", etag);
　}
#endif
出力部のチェックサムは、とりあえずcrc32を使い、
>>173を参考に、dat_read()の先頭でBigBufferをチェックするようにした。
また、影響を少なくするため、NotModifiedを返すのは混雑時のみにした。

出力情報は、%x形式で、
ETag: "crc-全サイズ-全レス数-送信部サイズ-送信部レス数-flag"
flagは出力が混雑時のものか、等。
かなり冗長で使っていない情報も出力しているが、
必要最小限にすべきか？
もし、ツール等が使う可能性があるなら、
to=nn以外のリクエストにも必要があるかも。

今のままだと、st=1&to=150とした場合、
時間帯が異なると必ず更新扱いされてしまう。
リクエストのレス全てから算出した値と
実際に出力するレスから算出した値を両方求め、
それぞれと比較して一致したら304を返す方が望ましい？

動作確認は、apacheをいれてないので中途半端にしか出来ていない。
・ETag出力の確認
・match_etagがtrue/falseを返す時の出力をそれぞれ確認
・HTTP_IF_NONE_MATCHをputenvして、datに手動で行を追加して確認
等はしたものの、
IEのリクエストから動作を確認したわけではないので、
ONにする前に(可能な人に)動作確認をお願いしたい。
NotModifiedを返す条件も募集中(追加をお願い)。

408 ：デフォルトの名無しさん ：01/09/18 07:09

ところで、昨日いろいろ調べて、ようやくcheckout出来た。
(今まで、sshでつまずいていた)
WinCVSではなく、コマンドラインから動かしているけど、
updateは正常に動いているようなので、
commitも動作自体は大丈夫だと思う(これからテスト)。

よく見たら、改行コードが変換されている。
まあ、これはcommitする時に戻されるだろうからいいとして、
他に気になるのは漢字コードか。
コメントを書くのにEUCで保存できないエディタを使ったり、
間違えてSJISで保存したりすると、化けるんだろうな。

ということで、ETagの動作確認の他に、commitの動作確認もお願い。

409 ：408 ：01/09/18 07:50

ちゃんとできたみたい。
でも、read.c以外は触りたくないし、
細かい修正は今まで通りここに書きこむ方が気楽だ。

410 ：デフォルトの名無しさん ：01/09/18 08:31

>>408
困ったことに(笑)
read.cとr2chhtml.hはSJISだけどread2ch.hやconfig.txtなどはEUCなんですよね。
文字コード自動判別&元の文字コードを維持してくれるエディタを使うようにしないと。

改行コードについてはWinCVSなんかはテキストとして扱うものは変換してくれますね。
バイナリファイルをaddするときはバイナリフラグをつける必要があります。

411 ：デフォルトの名無しさん ：01/09/18 08:43

>>407
need_etagを呼ぶタイミングだけど、
gzip対応かどうかを判定する前にBaddAccess()を呼ぶのはまずいっす。
etag判定時と実処理時で結果が違ってしまう。

325KB

---

新着レスの表示

---

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

0ch BBS 2004-10-30