---

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

read.cgi改良スレッド ２

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

旅客機テロの影響か書き込みがパタリと止んでいますが…。
1つ提案です。
REQUEST_METHODがHEADのときは、本体を読み出して
解析しても無駄なのでLast-ModifiedとContent-Lengthを
吐くだけにしましょう。

220 ：デフォルトの名無しさん ：01/09/12 23:21

絶対pathでも相対pathでも対応可能にするには、
sprintf(buff, "%s%s", *TEMP_DIR == '/' ? "":"../", ...)
のように、強引にやる方法もあるけど、
それよりも、夜勤さんにしろひろゆきにしろ、わかってるんだから、
#define TEMP_DIR "../%s/temp/"　　/* %s に板名がはいる */
のように、フォーマット文字列をdefineした方がやりやすいでしょ。
変更個所は>>201-202と同じで。

＞kako以下のフォルダの生成は関数の方がいいかも
ということは、kako以下の仕様も変更するかもしれないってことかな？
なら、
/* buffに、倉庫のサブディレクトリ名を生成する
両端の'/'はつけないこと。
例 key="999888777"のとき、buffには"999"を入れる */
#define kako_dirname_copy(buff, key)\
　strncpy((buff), (key), 3)/* 3桁固定 */
/* 999の次を桁にする場合は
　sprintf((buff), "%d", atoi((key)) / (1000 * 1000))
　にする */
のようなものを、そのままread2ch.hに入れてしまえばよさそう。

221 ：名無し娘。 ◆vP.bOZFQ ：01/09/12 23:45

実装・検討待ちの案一覧

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

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

CHUNK_ANCHOR NAME_ANCHOR
　nofirst=true をつけない（"最新レス50"にも）
　アンカーへのリンクは冒頭でなく下部に & target="_blank" する
　>>xxx はCHUNK単位で呼び出さない & nofirst=true をつけない
　　>>76

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,test,板 のpathをdefineできるようにする
　kakoへのpathは関数で生成する
　　>>191 >>196-202 >>216 >>220
　dat,temp,kako を read.cgi で読む
　　>>203-208
　datの一部についてのLastModを求める
　ツール作者さんに対応お願い
　　* raw=xxx.yyy の形式でリクエスト。 xxx=最終レス番号, yyy=そのときのサイズ。
　　* 一行目はステータス:
　　* [+OK] の場合は差分のみを送信する。
　　* [-INCR] (Incorrect)の場合はすべてのデータを送信する。
　　* [-ERR (テキスト)]の場合はなんかエラーが起きた。

condition一覧/SETTING_R.TXT記述一覧
　http://www.gedoh.org/aki/2ch/current/bbs/config.txt
　CUT_DATE_STRINGをON固定にする
　GZIP/ZLIBを整理
　追加すべきもの
　　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時に圧縮対応していないと弾かれる

222 ：名無し娘。 ◆vP.bOZFQ ：01/09/12 23:45

NN4.72でgzip圧縮&&Content-LengthがあるとLast-Modifiedが無効
　http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1000035521&st=872&to=872&nofirst=true

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
　そのうち対応

キャッシュであぼーんされたレスが見える？(詳細不明)
　http://teri.2ch.net/test/read.cgi?bbs=saku&key=996761078&st=408&to=408&nofirst=true

223 ：名無し娘。 ◆vP.bOZFQ ：01/09/12 23:49

あと、>>207 についてのご意見をお願いしますです。

224 ：125 ：01/09/12 23:50

とりあえず、あらかた組み込んだ。
#define DAT_DIR "../%.256s/temp" 方式
CREAT_NAME_ANCHORはoffにした。

SEPARATE_CHUNK_ANCHORの動きが気に入らない。
特に、busyの時が不自然かな。

tempやkakoのチェックが面倒だった。

225 ：125 ：01/09/12 23:52

書き間違いごめん
#define DAT_DIR "../%.256s/dat/"

226 ：125 ：01/09/12 23:56

>HEADリクエストに対しては Last-Modified と Content-Length を吐くだけにする
Content-Lengthを吐くためには全部やってみないと算出できない。
ZLIBでgzipの時にデータを吐かなくすることは可能。

227 ：名無し娘。 ◆vP.bOZFQ ：01/09/13 00:40

>>221
>CHUNK_ANCHOR NAME_ANCHOR
>　>>xxx はCHUNK単位で呼び出さない & nofirst=true をつけない
訂正。この場合は nofirst=true をつけるべきです（現状のまま）。

>>224-226
おつかれさまです。

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

「削除」はするけど「書き換え」はしないという方向かな？
基本的には賛成。
ただ、文字数を考えるとUSE_PATHの時は書き換えてもいいかも
(target="_blank"も結構長さを食う原因だけど)

229 ：125 ：01/09/13 01:12

Etagですが、ZLIB+gzip使用ならgzipが算出したCRC32をそのまま使う手もあります。
サーバー負荷は減らないが、転送量は減らせるでしょう。
ただ、対応部分のdatが何も変わっていなくてもhtml化の表現が変わると
無効になってしまいます。
23時に突入した時とか、レスが増えてanchorが増えた時とか。

>>222
NN4.xに対応するworkaroundは導入されてます。

230 ：名無し娘。 ◆vP.bOZFQ ：01/09/13 02:34

>>228
表示中のページ内に該当レスがある場合にのみ「削除」をする、
あとはなにもしない、ってことになります。>>207
target="_blank"がないのは、特に >>xxx の場合は不便なのでぜひ付けて欲しいです。
その他の場合（冒頭部のCHUNK、最新レス50、etc.）はつけない方がいいのかも。。。
>>229
同じことを raw=xxx.yyy の時にやる場合は、html化後の表現には左右されませんよね。
# html化しないんだもの(笑
raw=xxx.yyy ではないときに Etag をはくのは、raw=xxx.yyy なときと比べると
おまけかなと思っているので、それでもよいと思いますです。

231 ：125 ：01/09/13 03:11

>>230
あれ？Etagの目的は、
　ブラウザで部分読みの場合に出力に変化がないにもかかわらず
　新レスのせいでIf-Modified-Sinceが成立しなくなる。
の対策じゃなかったけ。
ついでにあぼーんチェックの強化に使おうというのは主目的ではなかったはず。

232 ：名無し娘。 ◆vP.bOZFQ ：01/09/13 08:09

>>231
失礼しました。私の勘違いです。

そもそも、raw=xxx.yyy の時に同一性チェックを行うのは、304を返すためではないので、
304を返すためにおこなうチェック(部分読みの時の同一性チェック)とは方向性が違いましたね。
# 具体的には、後者の場合、転送内容は「鯖側で同一性チェックにかけられる部分」に
# 確定している。前者の場合、転送内容は「.dat全部」か「鯖側で同一性チェックに
# かけられ*なかった*部分」のどちらかになる。
# 前者の場合(rawmode)の同一性チェックは gzip/zlib しないで行うべき、
# という認識で正しいですか？

233 ：デフォルトの名無しさん ：01/09/13 10:57

webブラウザでver5.20を見てみての>>207さんへの意見です
CHUNK単位のリンクは冒頭のままでよいかと思いますが、
・各CHUNK表示の下部に「次の50レス」へのリンクがほしいです
　最新表示の「新レスの表示」と同じ形式がよいと思います
・表示レス数50以下のCHUNKはいらないのではないでしょうか
　[(レス数-1)/50]*50-49 がトップにくるCHUNKまででよいと思います

234 ：デフォルトの名無しさん ：01/09/13 11:33

批判要望では、CHUNK単位のリンクが先頭にあると
読み終わった後でいちいち先頭まで戻るのがめんどくさい
という意見が出ていました。

235 ：デフォルトの名無しさん ：01/09/13 12:18

やはり一番下に前後CHUNKに移動する手段はほしいですね。
そうすることで一つひとつのページのバイト数は多少増えるかも
しれないけど、適切な誘導で無駄なページの閲覧を減らせるの
ならば、結果的に転送量の抑制にもつながるのではないかと。

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

あ、>>235は「CHUNK単位のリンクに加えて」という意味です

237 ： ◆D69Zsbfg ＠夜勤 ★ ：01/09/13 14:52

999999999 以前のやつは、いままで通り
http://kaba.2ch.net/news/kako/

1000000000 以降のは、こんなディレクトリ構成考えてます。
http://kaba.2ch.net/news/kako/10/000/
つまり今よりは複雑になるので、#define じゃやりにくい
ということです。他の dat落ち、html化等のcgi も随時改造中
ですので、kakoフォルダのロケーションは関数化していただけると
ありがたいです。

注文多くて、すみません。よろしくお願いいたします。

238 ：デフォルトの名無しさん ：01/09/13 16:51

やはりCHUNK_ANCHORは下にあったほうがいいという意見が
多いですね。

762 名前：名無しさんの声 投稿日：01/09/13 16:44 ID:a2dTsqos
"1- 51- 101- 151- 201- 251- 301- 351- 最新レス50"
って部分"新スレの表示"の左側にも付けてもらえませんかね？
いちいち上まで戻して次の５０表示するの面倒です。

239 ：デフォルトの名無しさん ：01/09/13 17:18

なるほろ。こんな感じ？

/* keyはkey=../kako/xxx等の場合でも、最後の"/"の次の位置が入る。
　普通は数値のみ(の先頭)が入っている。
　現在は、
　"999888777" → "999"
　"1000999888777" → "10/000"
　"1234999888777" → "12/234" */
void create_kakodirname(char *buff, const char *key)
{
　int tm = atoi(key) / (1000*1000);
　if (tm >= 1000) { /* 1000 Over */
　　sprintf(buff, "%d/%d", tm / 100, tm % 1000);
　} else { /* 994-999 */
　　sprintf(buff, "%d", tm);
　}
}

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

夜勤さんがさらにいじりやすい(read.c内の位置を探すのが面倒)ように、
read.cの一番最後に置くか、
↑を全部#ifdef READC_MAINで囲んでread2ch.hに置いて、
read.cを
#define READC_MAIN
#include<read2ch.h>
にしておくのがよい？

241 ：デフォルトの名無しさん ：01/09/13 17:24

read.c内で一箇所に固めておくに一票

242 ：239 ：01/09/13 17:25

コメント滅茶苦茶だった・・・

243 ：239 ：01/09/13 17:58

コメントはともかく、動作がおかしいのはまずい。ってことで、
　　sprintf(buff, "%d/%03d", tm / 100, tm % 1000);

244 ：デフォルトの名無しさん ：01/09/13 18:48

>>nnn形式のリンクをクリックするリクエストって、
全体からするとかなり低い割合なのかな？
すると、転送量に占める割合は、さらに極僅かかな？

>>nnnをクリックして読む場合って、
スレの別の部分を読んでいて、そこから参照するだけだから
書きこんだり、続きを読んだりする事ってほとんどないはず。
すると、１レス分の表示をするために沢山のリンクを提供して
javascriptでNAMEやMAILを取って、FORMを表示するのって、
(１レスを読むためだけには)すごい無駄な気がする。

refererを調べれば参照が元スレ(or index.html)かはわかるから、
その場合で、かつstとtoが同じでnofirst=trueの場合には、
レスの本文だけに特化して、それを返してもよさそう。

CHUNKや「次のnレス」を辿る場合にはカット出来ないから、
>>nnn-mmm形式のリンクにも対応するには、
stやtoの数値を見て判断するとか、
stとtoの差が10以内だったらカットするとか。

いずれにしても、最初に書いたように
変更個所が多岐に渡る割に、効果は不明だけど。

245 ：7743 ：01/09/13 22:13

ポ
倒れる
ソニック

246 ：名無し娘。 ◆vP.bOZFQ ：01/09/13 23:24

>>245
0x7cのテスト？？

247 ：ghanyan ：01/09/14 00:32

マイナーな2chブラウザを作っている、ghanyanです。
今回、まず初取得時にread,cgiのRAWモードを使おうと思ったのですが、
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=982853418&raw=0.0
では、スレにある\x00の連続が削られてしまい、read.cgiのリザルトコードを
除いた部分が元のdatファイルと一致しません。 これが一致してもらわないと、
過去ログあたりがみんな無効になったり、更新時にはread.cgiを介さない場合に
とても困るんですが。 (URL:http://www.geocities.com/ghanyan/ )

248 ：名無し娘。 ◆vP.bOZFQ ：01/09/14 00:53

>>247
ご報告ありがとうございます。確認しました。
rawout時には.datをいじくらないようにしないといけないですね。

249 ：デフォルトの名無しさん ：01/09/14 00:57

printfだから\0を含む行を正しく出力できないわけね。
zlibにはバイナリ出力用の関数ってあるの?
pPrintf(pStdout, "%.*s", BigLine[i+1] - BigLine[i], BigLine[i]);

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

こうすればOK?
if (gzip_flag)
gzwrite(pStdout, BigLine[i], BigLine[i+1] - BigLine[i]);
else
fwrite(pStdout, 1, BigLine[i+1] - BigLine[i], BigLine[i]);

251 ：125 ：01/09/14 02:27

テロ以来コードをcommitする人がいなくなっちゃたな。
私しか差ワット欄。

>>237,239-243あたり
kako_dirname()をread.cの最後に付けた。
>>247-250
dat_raw_out()のデータ出力をprintf系からwrite系に変えた。

252 ：125 ：01/09/14 02:39

いいかげんに上部と下部に付けるanchorを決めたいところだが。
上：掲示板に戻る 1- 最新レス50
下：次の50レス 1- 51- 101- ... 最新レス50

批判は出るだろうが、bbs=tech&key=xxxxだけの時は、1-50表示にすると
転送量減るんじゃないか。
スレの紹介で範囲を指定しないことが多いわりに全部読むことは少ないと思うが。
全部読みたきゃ、st=1を指定しなさいということで。
削除人は困るのかな？

253 ：デフォルトの名無しさん ：01/09/14 02:45

>>252
上は現在の範囲より前だけ
下は現在の範囲より後ろだけ
のほうが節約できると思うけどセコすぎ?

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

>>253
それすでに実装されてるよ。
SEPARATE_CHUNK_ANCHOR

255 ：125 ：01/09/14 03:14

>>253
下から上に読む人がどのくらいいるかによるんじゃないかな。
50もさかのぼりながら読むようなら、次は１から読みたくなるんじゃ
ないかと思うけど。

途中から読みたいことがそんなになければ、

上：掲示板に戻る 1- 前の50レス 次の50レス 最新レス50
下：1- 次の50レス 最新レス50

なんてのもありだと思う。

256 ：125 ：01/09/14 03:17

>>254
実装されているかどうかじゃなくて、推奨設定を決めたい。
いつまでもテスト段階じゃしょうがないでしょ。

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

>>252
>批判は出るだろうが、bbs=tech&key=xxxxだけの時は、1-50表示にすると
>転送量減るんじゃないか
　これ名案だと思う（笑）
様子を見るためにクリックしたが、最後まで読む気ないけど全部
表示されるってパターンは割とありそう。

>>255
さかのぼるってのは相対的にかなり少ないんじゃないかと思うけどどうなのかなあ。
古い順に読むのに比べて。

258 ：デフォルトの名無しさん ：01/09/14 03:25

>>252
>批判は出るだろうが、bbs=tech&key=xxxxだけの時は、1-50表示にすると
うーんしかし、もともとテレホタイムは全部表示しないようになってるような。
ピーク転送量(=テレホタイム)の削減目的では、何も変わらないか。

259 ：デフォルトの名無しさん ：01/09/14 03:25

>様子を見るためにクリックしたが、
あるある。最新レス50だと最初のほうが読めないから
「レスを全部読む」をクリック。
ただbbs.cgi側にも「レスを最初から読む」に変えてもらうとか
協力を仰がないと「全部表示されません」という文句が
批判要望に殺到しそうな気がする(w

「さかのぼる」については、マーフィーの法則風に言うと
「自分の読みたい参照先は、常に表示範囲の1つ前である」
ので上にはほしい。下にはいらないけど。

260 ：デフォルトの名無しさん ：01/09/14 07:06

転送量を削減するという名目でひたすら弄ろうとしているように見受けられる。
使い勝手を犠牲にしてまで機能を制限するのは混雑する時間帯だけでいいのでは。
それも、極力操作の変更を伴わない機能制限で充分です。
8月末までの一連の対策で転送量削減の結果は出たはずです。
操作方法を著しく変えて不便を利用者に強いてまで、これ以上の転送量を削減する
要望が管理側から出ていたでしょうか？
開発者はどこを向いて誰のために開発しているの？

261 ：デフォルトの名無しさん ：01/09/14 08:33

＞8月末までの一連の対策で転送量削減の結果は出たはずです。

何寝ぼけたこと言ってんの？
板閉鎖と過去ログ閲覧禁止と強制IDでようやく目標に達しただけなのに。
自分のいる板が閉鎖されてないから他のことはどうでもいいってのが見え見え。

262 ：デフォルトの名無しさん ：01/09/14 08:39

>>260
＞それも、極力操作の変更を伴わない機能制限で充分です。

それはお前が決めることではない。

＞操作方法を著しく変えて不便を利用者に強いてまで、これ以上の転送量を削減する
＞要望が管理側から出ていたでしょうか？

出てるよ。不便だと思うなら2chに来なければいい。お前の分の転送量が減る。

263 ：デフォルトの名無しさん ：01/09/14 08:47

>>261
一時の閉鎖とは打って変わってほとんどの板が順次復活してます。
過去ログ閲覧も順次復活してます。
縮小路線維持であればニュース速報板が何枚も増設されなかった。
状況は刻々と変化している。

>>262
＞それはお前が決めることではない。
プログラマが決める事なの？

＞出てるよ。
どこに？

264 ：デフォルトの名無しさん ：01/09/14 08:57

>>263
運営側から「もう充分だ」と言われていない。
まだ試行錯誤の段階で、転送量についてもまだ様子見の段階であることは
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=998808733&st=780&to=780
でも明らか。結論を急ぐな。

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

ここでどんなにread.cgiをいじくろうが、その採用を強制する力はここにはない。
最終的に何が実装されるかは運営側の判断に委ねられている。
建設的な提案ならともかく「これ以上やるな」というのはここで喚いても無駄。

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

某ツール作成者ですが、rawモードのときステータスといっしょに差分サイズを送るようには
出来ないですかね？

＋OK 3093
みたいに。
そうすればブラウザ側とのサイズの認識のずれはなくなるし、こちらとしてもやりやすいので(^^；

あと、どのサーバーにどのバージョンのread.cgiが入っているとか、こうすればバージョンが判るぞ、
って言うのはどこかに情報ありませんか？
探したんですがちっと見つからなくて・・・

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

今の版だと、
304を返す時にも
Content-Type: text/html
を出力しているけど、いらないでしょ。

　puts("Content-Type: text/html");
(#ifdef RAWOUT以降)は
　putchar('\n')
の直前でいいと思う。

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

相変わらずバカだね。
>一時の閉鎖とは打って変わってほとんどの板が順次復活してます。

そんなこと、みんな知ってるよ。
だけど、お前の言う「結果は出たはず」ってのは
板を閉鎖している時点でのことだ。
資金的な目処がたった等の理由で板は復帰してるけどな。

キミはもしかして、
dat直読み禁止になっても
「かちゅ〜しゃで読めないのは改悪だ」
「どこからも要望は出ていない」
と叫びつづけるのかい？

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

制限や規制は２ちゃんねるの基本方針ではない。それがいい事か悪い事かは別として。
利用者の利便を否定して不便を享受させる権限がプログラマにあるのかな。
そういう実験や遊びこそ２ちゃんねる外でやってほしいものです。

＞結論を急ぐな。
早急に開発したり機能を変更する局面も過ぎ去ったように感じます。
逆に、開発を急ぐな。変更を加えるな。と言いたい。
夜勤氏から要求のあった機能を除いて。

＞まだ試行錯誤の段階で、転送量についてもまだ様子見の段階
Gzip転送を組み込んだ時は効果がすぐに出た。
今回の機能変更は様子を見なければ分からない程。
仮に減少しても、利便を損ねてまで得る価値があるのかどうか。

＞最終的に何が実装されるかは運営側の判断に委ねられている。
それを都合のいいようにとってませんかな。
要求のある機能の開発のみにすれば判断も必要ない。

＞建設的な提案
極力開発しない事を前提にしてという要望は、建設的な提案ではないのでしょうか。
今までの機能で困ってない利用者のニーズはどこへ。
開発第一の発想しかないのですかな。

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

そうそう、
>>206の
＞dat の直読みは、転送量の節約を鑑みて、できなくする方向です。
を読むだけでも、
「まだ、転送量の削減は求められている」
と言いきれるね。

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

>利用者の利便を否定して不便を享受させる権限がプログラマにあるのかな。

きみは他人の話を全然聞いてないみたいだね
そんな権限はプログラマにはないよ。
決定権を持っているのは別の人だってさっきから言われてるだろ、ヴォケ。

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

全てのケースでTry＆Errorを行なうものではないですよ。
長期間を経てVer.5にもなっているのに、この期に及んで試行錯誤しなくてはいけない状況を
作り出すこともないですよ。

＞dat の直読みは、転送量の節約を鑑みて、できなくする方向です。
変更したり追加しなければならない事情があれば、夜勤氏からちゃんと話を持ちかけてくる。
とも言えます。
それ以外の機能改変は要求がありませんよ。

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

なかなかいいキャラだけど、
このスレにしろ、動作報告スレにしろ、
騒げば騒ぐほど、
状況を把握せずにわめいているのは一人だけで、他の多くの人はそうは思ってない。
ということを強調する結果になるだけ。

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

＞＞dat の直読みは、転送量の節約を鑑みて、できなくする方向です。
＞変更したり追加しなければならない事情があれば、夜勤氏からちゃんと話を持ちかけてくる。
＞とも言えます。
＞それ以外の機能改変は要求がありませんよ。

まだ言ってるよ。
「転送量を削減する必要がある」と夜勤さんが言ってるんだろ？
その程度すら読み取れないのか。

275 ：デフォルトの名無しさん ：01/09/14 10:30

＞わめいているのは一人だけ。
主張しているのは俺一人ではないですよ。
わめいているとしか受け取っていないとは、随分厳しいですね。
開発者の立場だけではなく、利用者の立場の意見も心に留めてほしいものです。
開発者の反発はある程度予期していましたけれど、違った意見に対してバカだの
ヴォケだの罵ってるのを目の当たりにすると先が思いやられます。
都合のいい拡大解釈や先走りは程々にお願いしたいものです。
ともあれ、最終的に管理者や利用者が納得する結果に落ち着く事を希望します。

276 ：デフォルトの名無しさん ：01/09/14 10:35

>>191の
>転送量は、機能が増えたのに　増えも減りもしなかった。
>CPU等への負荷は、若干上がった。
つまり、動作報告スレの780
>機能が増えて転送量に変化がなかった　= 転送量を減らす効果があった
>と理解しています。
を
>機能を変更した事により、使い勝手の不便だけではなく、トータルに見て転送量にも
>さしたる改善が認められなかったと報告があった。　>>766
と「俺解釈」し、
>>206の
>dat の直読みは、転送量の節約を鑑みて、できなくする方向です。
を読んでも、
>これ以上の転送量を削減する要望が管理側から出ていたでしょうか？
と訴える。

だいたい、開発者だって利用者だ。
不便になるだけの変更はするわけがない。
自分の考えが絶対正しいと思っているのだろうが、
複数の人間が開発しているのだから、
妙な意見がそのまま通るわけがない。

前スレあたりから通して一遍読んでみろ。
自己満足機能は確かにあるが、削られているものもある。
批判や要望も取り入れられて修正もされている。
現在運用されているバージョン以降にもな。

277 ：デフォルトの名無しさん ：01/09/14 10:36

都合のいい拡大解釈

良い言葉ですね。

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

>>276
聞かれたので意見を述べます。
これは夜勤氏の解釈ですけど、転送量に注目して言えば、
転送量が減った＝転送量を減らす効果があった　と判断するのは分かりますが、
増えも減りもしなかった＝転送量を減らす効果があった　になるのは不自然ではないでしょうか。
転送量を観察するのには、少なくとも一週間は必要です。と述べている割に、
その時点で効果があったと判断するのは、それこそ早計ではありませんか。

279 ：デフォルトの名無しさん ：01/09/14 10:57

>>267 いや......Content-Typeを吐かないと　例えば

#!/bin/sh

echo 'Status: 304 Not Modified
'

というので実験してみたところ

HTTP/1.1 304 Not Modified
Date: Fri, 14 Sep 2001 01:55:00 GMT
Server: Apache/1.3.20 (Unix) ApacheJserv/1.1.2 mod_gzip/1.3.19.1a mod_ssl/2.8.4 OpenSSL/0.9.6b
Connection: close
Content-Type: text/plain

となった　Content-Typeを指定しておかないとDefaultTypeが返されてしまうようだ

280 ：デフォルトの名無しさん ：01/09/14 11:02

276のどこで聞いてるんだ?
脳内妄想垂れ流すのもいい加減にしろ。

281 ：デフォルトの名無しさん ：01/09/14 11:04

780 名前：夜勤 ★ 投稿日：01/09/14 00:29 ID:???
一日の間にも、当然ピークがあり
また、一週間の間にも波があり、、、
さらに、板によっても使われ方が違います。

転送量を観察するのには、少なくとも一週間は必要です。
出来れば、数週間欲しいところです。

誤解の無いように、
機能が増えて転送量に変化がなかった　= 転送量を減らす効果があった
と理解しています。

機能が増えて
機能が増えて
機能が増えて
機能が増えて
機能が増えて
機能が増えて
機能が増えて
機能が増えて
機能が増えて
機能が増えて

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

名前： や　sageだけのメール欄（色変更だけにする）　削った場合ってなにか問題が起こるのでしょうか？
あと、見た目悪いし、普段はIDまで見る必要はない人も多いと思うので、
強制IDの板でもID表示しない表示モードを作る事は実用的に可能ですか？
（できれば１が表示をコントロール出来る様な物を、デフォルトのモードにするかは別問題として）

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

sageだけの場合メール欄のアンカーを表示しないのは
実装済みです(SAGE_IS_PLAIN)。
ただしアンカーの代わりに<font>が入るので、効果が
薄いです。
スレ立て時にID表示を選べるかどうかという話はスレ違い。

284 ：名無し娘。 ◆vP.bOZFQ ：01/09/14 11:19

>>282
「名前：」は「：」にしていいと思いますー。

sage のみのメール欄は SAGE_IS_PLAIN として実装済ですが、
今まではリンクがあったものを色変更だけにすることが、２ちゃんねるの
楽しさを損なわないか（age や sage が一見分かりにくいとか、
sage だと思って見ると (ﾟдﾟ)ｳﾏｰ だったりとか）、そうでなくても勝手に
機能を変えることには抵抗があるでしょうから、私はおすすめできません。

１がコントロールして ID 表示しない云々は、１のメール欄に noid とかがある場合に
"ID"以下を切り落とすなどの方法で可能です。将来的な需要はあるかもですから、
実装してみるのもいいかも。

285 ：デフォルトの名無しさん ：01/09/14 11:26

>>284
IDを表示しない(というか出力しない)ようにするのは
bbs.cgiの領分ではないでしょうか。
もちろんdat直読みが禁止されれば理論的にはread.cgi
だけで対応も可能ですが…。

286 ：名無し娘。 ◆vP.bOZFQ ：01/09/14 11:31

bbs と key のみの時に ls=50 するのであれば、「全部読む」用のオプションが
ほしいです。st=1 がその働きをするのでも構いません。

あと、混雑時間帯以外は、冒頭に「レスを全部読む」がほしいです。
確か、夜勤さんが 5.20 を入れてくださったあと、そういう要望が出てそのように
実装され直したと思いますが、念のため。

287 ：デフォルトの名無しさん ：01/09/14 11:30

424 名前： ◆WinMIRVY ＠マァヴ ★ 投稿日：01/09/09 18:14 ID:???
(中略)
>>423
どっちかっていうとIDを導入するかどうかの問題じゃないかな？(^_^;)それって
今のところIDは、板内での発言者の同一性を明かにするのが目的であって
その目的を否定するならID非導入ってことになるんじゃないかと・・・・。
んで、ID導入が２ｃｈとして妥当かどうかはおいらは関知しません。
あくまでID値の安全性についてだけね(^_^;)

288 ：名無し娘。 ◆vP.bOZFQ ：01/09/14 11:35

>>285
本来はbbs.cgiの領分だとは思います。
「強制IDの板でID表示しない」とのことだったので、read.cgiが簡易にそういう
振る舞いをするのもありなのかなぁ、と思ったのです。
rawmode の際も dat から ID 部分を切り落とすのはさすがに問題でしょうから、
専用ツール読みが流行ることになるのかな。
まあ、運営の皆さんがそういう実装をほしがるようにはあまり思えませんね。
# なんて推測で書いてはいけないかな(汗

289 ：デフォルトの名無しさん ：01/09/14 12:24

>>275
＞＞わめいているのは一人だけ。
＞主張しているのは俺一人ではないですよ。

どこに「開発するな」なんて主張している人間がいる？
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=1000218329
のスレの15=17=キミ以外に。
他にいたら、是非教えて欲しいな。参考にしたいから。

「全部読む」を戻せとか、
>>nnのリンクを戻せとか、
個別に、かつ具体的に書いてくれている人はたくさんいるし、
それらに対しては導入されていないだけで、ちゃんと対応されている。

290 ：not 289 ：01/09/14 12:41

>それらに対しては導入されていないだけで、ちゃんと対応されている。

[一応わかりやすいように補完]

それらに対しては「現時点では」導入されていないだけで、「修正中のプログラムでは」ちゃんと対応されている。

291 ：125 ：01/09/14 12:51

上下に配置するもののを決めるのに意見を出してくれるかと呼びこんでみたが、
掻き回すだけなのか。
未だに、どうするのがいいのか模索しているってことに気付きもしないとは。
これが必要で、これは要らないってのを決める役にたちやがれ。

CHUNK単位へリンクしないのなら、CHUNK表示は要らないと思いますがいかかでしょう。
いったん機能を固めて内部の安定化を図りたいのですが。

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

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

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形式じゃないと思い込んでた。後半しか見てなかった。失礼しました。

326KB

---

新着レスの表示

---

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

0ch BBS 2004-10-30