---

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

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

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ではないかと思います。
そのために、不必要(かもしれない)な時間帯による場合分けや
外部ファイルによる設定変更等の追加が求められるとしても、
試行錯誤している段階では、できるだけそのようにコードを作るのが
理想ではないかと思っています。いかがでしょうか。

325KB

---

新着レスの表示

---

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

0ch BBS 2004-10-30