---

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

read.cgi改良スレッド

701 ：デフォルトの名無しさん ：01/09/05 13:47 ID:Il0l9chs

CFLAGSに"-march=i686"って入れても大丈夫かな？

あと実運用のではLDFLAGSに"-s"って入れた方がバイナリサイズが小さくなる
ので　その分CGI呼び出しでの負荷が軽くなる......かな？

702 ：♯6411 ：01/09/05 14:50 ID:2LugT.hk

>>701 ld -s でやってるわけじゃないけど
make strip ってのが用意されてる。

703 ： ：01/09/05 21:26 ID:ZOwDxD/w

read.cgi ver5.12 (01/9/5)

704 ：♯6411 ：01/09/05 21:31 ID:zceo8xV2

>>703 まだまだだねー

漏れは別の仕事が入ったので、休憩中。

705 ：デフォルトの名無しさん ：01/09/05 21:32 ID:F4TkSYjU

>>703
これってcvsのソース持ってってくれてるのかなあ?

706 ：デフォルトの名無しさん ：01/09/05 21:48 ID:F4TkSYjU

>>705
されてなさげか

707 ：デフォルトの名無しさん ：01/09/05 21:52 ID:d3E9QeVc

ここの成果を参考にしつつ、夜勤さんが管理しているソースを夜勤さん自身が
メンテしているのだろうね。トラブルも怖いし転送量削減に関係ない部分の
アグレッシブな変更はやはりちょっと手を出しづらいのであろう。

708 ：名無し ：01/09/06 00:31 ID:4dWQq6IU

sage でやってると夜勤さんは気付かないらしい。
みんなから、もう忘れ去られてるし。

709 ：辛口 ：01/09/06 00:56 ID:TLbpbvsU

俺だけかもしれないけど、新しいおもちゃを買ってもらった子供の気分だったね。

read.cgiに新機能なんか要るわけない。
何か別な機能が必要になれば、別途用意すればいい。
余計な機能は邪魔。

便利になるようにするのはいい。
ただ、それがピーク転送量や負荷に影響する可能性があれば
簡単に時間帯制限を設けたり、機能を外したりできるようにしておくべき。
(ほとんど影響しないならば、是非取り入れるべき)

とは言っても、決めるのはここにいる誰かではなく、
夜勤さんであり、ひろゆきである。
特にread.cgiには夜勤さんの決定が最重視されるだろう。
もちろん好き嫌いで決めるのではなく、いろいろ試し、
転送量や負荷を調べ、結果を見て判断するだろう。

ただ、現状のシステムを変化させる必要があるような機能は
夜勤さんはおそらく取り入れない(変更できない)。
現状に合わせて、その中で最善な機能を選択すると思われる。

read.cgiに求められるのは、ピーク時の転送量と負荷の削減。
忘れられかけているが、転送量問題が表面化するまでは、
サーバー負荷が最大の懸案だった。
特殊機能があっても使わなければ同じとは言っても、
ここ(2ch)は、他の人や組織から悪意を持って攻撃される事もある(あった)。
負荷が増える可能性も全て消しておかなければならない。
復帰作業が、スクリプト名を公開せず、
サーバーや時間帯によって厳しく決め事を設けているのを考えればわかるだろう。
便利な機能でも、負荷がかかるようならおそらく外される。

index.htm[l]から"投稿日"が消え、レスから曜日も省かれているのに、
read.cgiは投稿日を非表示にするオプションも(まだ)ない。
文字通り「１バイトを削る」という作業を行っているのに、
常時全レスにアンカーを設定する事に、夜勤さんは同意するだろうか。
natto等に導入されていたread.cgi Ver4.23には、
読みこみdatの最大値を時間帯によって変動させていた。
(もちろん、サーバーの負荷を考慮して。実際、bbspinkの最大値が変更された)
こんなオプションも(まだ)ない。
こういった基本的な点をもう一度重視して、
安定化を図るべきではなかろうか。

で、良さそうと思えるバージョンが安定したら、
そこで簡単なオプション説明でもつけて夜勤さんに推薦するといいのでは？
ここでずっと続けているから、夜勤さんも安定していないと考えて
取り入れないのかもしれない。

710 ：♯6411 ：01/09/06 01:00 ID:ae./7xbU

>>709 「新しいおもちゃ」の部分は禿胴。

711 ：　 ：01/09/06 04:01 ID:IAYQ/SXs

楽しげな新機能を思いつきました。
新規ログ１０件表示にして、表示順を逆にして新しいレスを上に表示する
書き込み後再び、この１０件表示にすれば、チャットモードの完成。

実況スレがさらに活発化！（あかんやん・・。）
このモードでは、無駄な部分は徹底的に削って超簡易表示モード
日付も時間も表示する必要は無い。
一行レスが乱れ飛ぶ事必死！（笑）

712 ：デフォルトの名無しさん ：01/09/06 08:22 ID:0iK.UQWw

>>709
同意

「こんなん作ってみました」じゃなくって、「ここをこう変更するだけで
○○の低下は××程度に抑えたまま転送量をここまで削減することができます」
という具体的な数字を挙げながら説明をして、変更のリスクに見合うだけの効果が
確実と説得できないと採用されないと思うよ。
＃リーマンなら当然分かると思うが。

だからここで30個アイディアが出てそれをこのスレのバージョンですべて採用しても
本番環境では29個ボツになるかもしれない。

それを分かった上でいろいろ試すのはいいんじゃないかと思うけど。
このスレももはや直接的な実装よりも、そういう斬新なアイデアが
出てこないかという部分で期待されてるんだろうし。

713 ：デフォルトの名無しさん ：01/09/06 08:36 ID:x54XUUQc

更新日：とか年の上2桁、曜日の削除って、圧縮かからないときにしか
ほとんど効果ないよな。
圧縮かけられないリクエストって全体のどれぐらいなのかな。

714 ：デフォルトの名無しさん ：01/09/06 12:57 ID:iopuCCXI

現在がサーバ負荷よりも転送量に重大な問題があるなら、
指定した板の指定したレスの生データを吐き出すCGIを
用意してくれないかな。

monazillaで利用されて少しは転送量軽減の足しになるのではあるまいか。

715 ：♯6411 ：01/09/06 13:02 ID:EWT7f5cU

正直、採用されない(採用されたがらない?)コードを
いじくりまわしてるのは、モチベーションが下がる一方で。

いろいろ問題提起もあったんで、もしこの
プロジェクトを続けるんなら、仕切り直しもしたい。

「誰でも気楽に改造を施すことができる」
「評価とかレビューのプロセスが欠落している」
などが、漏れ的には大きな問題になってると
考える。後者は、モチベーションが上がんないと
誰もレビュー買って出ない、というのもあるけど。

また、プロジェクトマスターに相当する人間が
いなかったので、実装の方向性が固まってなかった
とゆーのもある。漏れが突っ走りすぎたのも、
単に歯止めが利かなかっただけ(ｗ

漏れ的には、「バイト数低減と転送量低減のバランス」
「ローカルキャッシュおよびキャッシュサーバへの
キャッシング効率」「実装の軽量化」「潜在バグの追放」
を睨んであれこれ手を出してた。
あ、あと、「ｵﾅｰﾆ」「換骨奪胎」もだな(ｗ

ちうわけで、もうしばらくは、唯一コテハン晒して
生き残ってる漏れが、取りまとめ役に回っても
構わんのだが、どーよ?

実際の実装にまつわるギロンはまた後ほど。

716 ：♯6411 ：01/09/06 13:48 ID:TE3IkoNg

>>709 一点だけ。

> index.htm[l]から"投稿日"が消え、レスから曜日も省かれているのに、
> read.cgiは投稿日を非表示にするオプションも(まだ)ない。
> 文字通り「１バイトを削る」という作業を行っているのに、
> 常時全レスにアンカーを設定する事に、夜勤さんは同意するだろうか。

夜勤さんが同意するかどうかは置いといて。
投稿日を非表示にするか否かに関して、
ここでは「全部削れ」という意見は出なかったので
誰もその方面に手を着けなかった、と考えるべき。
むしろ、「曜日は復活させてほしい」という意見の
方が多かったと感じてる。(俺もそう思う)
ちなみに、現在の仕様だと、内部で投稿日を
解釈してるので、(曜日の表示を含め)日付フォーマットを
自在にいじるのは簡単。

あ、「投稿日」という文字列を削る話?
ぞぬで見てたから気づかなかった。

あと、アンカーの件は俺の改造を指してると思われ。
俺的な考えでは、局所的に見たらバイト数の増加に
繋がれど、大局的に見たらリクエスト数の軽減に
繋がるのでは? と考えて試験的に導入。
この手の仕様に関しては、いくら思考実験を繰り返しても
結局のところ実地テストなしには最終的な評価が
出せないと思うが、いかが?

path仕様でない箇所で<A name=x>を出してるのは
俺の手落ち。機会があったら禁止しとくっす。

個人的な意見では、1バイトでも削る作業より
他にすることはまだある。

最終的に判断するのは夜勤さんであり、ひろゆきさんで
あるという事実には同意。ただ、キャップが誰も
意見を言ってくれない(放置?)以上、その手前の
レベルでとりまとめを行う人間は必要。

717 ：♯6411 ：01/09/06 14:04 ID:.R/e0Ey.

>>712 今後検討する仕様に関しては、
効果予測の文と一緒に提案することにするっす。

ただ、リーマン稼業と違い、
「とりあえず実装してみた、評価頼む」は
大いにありなのだと考える。
以前ｳﾆｸｰｽ板見てた連中に、ここがなんて言われてたか
覚えてる? 「理論ばかりで実装が遅れてる」(←揚げ足歓迎)
なので、漏れはまず実装して、それをたたき台にしたい
と考えた。結果的には、安定版がつくれないので、
ちょっとマズい方針だったんだが。

というわけで、「新機能実装ブランチ」を「バグ取り安定」から
分けないと、作業がしにくいなあ、と昨夜思った。

ちなみに漏れも、いわゆるリーサラだけど、
クライアントに提案して尻込みされた例は数知れず。
説得して採用させたことも多いけどね。

718 ：デフォルトの名無しさん ：01/09/06 19:19 ID:nYC88wV.

自己満足でやりたいなら、勝手にやってれば？

719 ：名無し娘。 ◆vP.bOZFQ ：01/09/06 23:23

>>716
おそらく「投稿日」という語句そのものを削る話だと思います。

>>717
>「とりあえず実装してみた、評価頼む」は
>大いにありなのだと考える。
それは同感なのですが、評価対象がふくらみすぎて、しかも、どこで
defineなりをすればどこがどう変わるのか、途中からさっぱり不明に
なってしまったと感じています。#ifdef の字面と内容が噛み合わない
部分さえ出てきた始末で。
評価してもらうのに最良の方法は、私は結局、全設定を外部ファイルによって
動的変更可能にすることだと思います。
そのこと自体が負荷増を伴うのは確かですが、それなら評価が終わって正式
採用の決まった設定から順に、再び内部定義に切り替えればいいのですし。

もし今後も続けるのでしたら、現行read.cgi(ver5.12/ver5.0x)に対し、
新たな選択肢を提起する形で、もう一度実装をし直す必要があるように
感じます。

720 ：音楽侍 ◆NtVkSITE ：01/09/07 00:08

火急的な課題がなくなったんだったら、そして、今後も改良作業を続けるのだったら、read.cの変更を出来る人を決めるだけでだいぶ違うと思うです。
read.cｎ変更権にパーミッションかけるだけで、だいぶ作業が効率化すると思います。

今までは時間に追われてましたけど、これからは効率化だけ見ていくべきだと思います。
あと、「こういう機能はいかがですか？」と、夜勤さんなどに確認をとるというのがもっとも効率的だと思います。
これまでの経緯から、私は名無し娘。さんがリーダーになるのが良いのでは？と思います。

721 ：名無し娘。 ◆vP.bOZFQ ：01/09/07 00:16

>>720
私は、いわゆる「プログラムは読めるけど書けない」人種ですので、ご勘弁を。
#6411さんのようなしっかりとしたコーディングをなされる方が仕切らないと
何もできないlevelに達していると感じます。

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

u

723 ：(ﾟДﾟ)ﾊｧ?スレ発起人＠批判要望板 ：01/09/07 00:29

はじめましてー
詳しく read.c のソースは読んでないのですが

/* SJIS1バイト目＝<br>タグ直前の空白が削除可かを適当に判定 */

IE等では>>722のようなことになるので，
datファイルの<br>前の空白だけでなく，
datファイルの各行末にある<>前の空白も
削除可能かどうか判定されると完璧ではないかと思います．

724 ：♯6411 ：01/09/07 00:32

>>720
> 今までは時間に追われてましたけど、これからは効率化だけ見ていくべきだと思います。
同意。内部的には、効率化・安全化を進める
べきなんでは〜と。
漏れのコードは安全化より重要な「自己満足化」が多いのだが(ｗ

> あと、「こういう機能はいかがですか？」と、夜勤さんなどに確認をとるというのがもっとも効率的だと思います。
漏れは夜勤さんﾊｧﾊｧではないので追いかけ切れんす。
どなたか、この点のフォローをしていただければ。

>>721
「読める」人間こそ、取りまとめに必要ではないかな?
漏れは「掻けるけど嫁ない」人間なので(ｗ

さしあたっては、ブランチを設けることを提案。

725 ：709 ：01/09/07 00:54

反論は煽り系のキャラで逝ってみる

>>716
＞あ、「投稿日」という文字列を削る話?
＞ぞぬで見てたから気づかなかった。
関連スレや意見を読んだりすれば、
どういう状態になっているか、板を開いてみる程度はするのが普通。
現状を認識しようとする意志が全くないわけね。
現状を把握せずに機能を提案できるなんて、すばらしい。

＞俺的な考えでは、局所的に見たらバイト数の増加に
＞繋がれど、大局的に見たらリクエスト数の軽減に
＞繋がるのでは? と考えて試験的に導入。
試験的に導入した割に、完全に書き換えてしまうわけね。
戻せるとはいえ。「俺的な考え」を基に。
で、コンパイルが通らなくなったりしても、
尻拭いは後回しにして、結局他の人がすることになるわけだ。

＞この手の仕様に関しては、いくら思考実験を繰り返しても
＞結局のところ実地テストなしには最終的な評価が
＞出せないと思うが、いかが?
その通り。だから？
簡単にテストができるようにしておけばいいものを、
まるで仕様が確定したかのように扱うのはどうかと思うが、いかが？

>>717
＞個人的な意見では、1バイトでも削る作業より
＞他にすることはまだある。
個人的な意見なんでしょ。他人に押し付けないでよね。
ま、ある程度は同意するけど。
そもそも「１バイトを削る」自体が夜勤さんの言葉からの引用だけど、
それも読んでないんだろうね。

＞「とりあえず実装してみた、評価頼む」は
＞大いにありなのだと考える。
その通りだね。
普通は評価前に仕様確定するようなやり方はしないけどね。

726 ：709 ：01/09/07 00:54

あ、俺はリーダーに最も適任なのは夜勤さんだけど、忙しいだろうし
それ以外では名無し娘。 ◆vP.bOZFQさんが適任だと思うね。
関連スレのチェックもしているし、重視すべき事項を一番わかっていると思う。
直接コーディングなんかできなくても、
機能追加の方向性やスケジュール等を把握して示してくれれば充分。
以前から、要望やらをまとめたりしてくれてたしね。

既に実装済みの機能や不具合の修正もいくつもあるのに、
(zlib等の他にも、ぱっと見で>>687とか>>559とか。>>606は未？)
fix版が出せないのは悲しいからね。

727 ：名無し娘。 ◆vP.bOZFQ ：01/09/07 01:11

>>724 >>726
ボランティアの作業で、仕切る人間が口だけじゃまずいと思いますです。
あくまでコーディングをする人にすべての権利があり、それを承知の上で
周りの人もそれぞれの意見をいう。。。という共通意識が何より大切かと。
ですから私が仕切るわけにはいきませんです。

夜勤さんがread.cgiにどれくらいの時間を割けるのかは、わかりません。
ですがやはり、いくらソースが長くなっても、オリジナルのソースと改良案は
（部分毎に）並行して提示しないと、採用には抵抗があると思います。

そろそろ、replace系の関数を最適化する方が先なのかもしれませんね。

728 ：♯6411 ：01/09/07 01:13

ﾏﾀｰﾘと逝くよ…

> 現状を認識しようとする意志が全くないわけね。
> 現状を把握せずに機能を提案できるなんて、すばらしい。

ｵﾅｰﾆだったんだよ、所詮。


> 試験的に導入した割に、完全に書き換えてしまうわけね。
> 戻せるとはいえ。「俺的な考え」を基に。
> で、コンパイルが通らなくなったりしても、
> 尻拭いは後回しにして、結局他の人がすることになるわけだ。

同意。自分じゃ条件外すことはめったにしないしのー。


> 簡単にテストができるようにしておけばいいものを、
> まるで仕様が確定したかのように扱うのはどうかと思うが、いかが？

放置されてて誰も構ってくれないので、
(うん、外せといわれたら即座に外せはするんだけど)
外す方法を吟味せずにcommitした漏れはダメダメだ。


> 個人的な意見なんでしょ。他人に押し付けないでよね。

ｵﾅｰﾆなんだ、言わせてくれよう。


> そもそも「１バイトを削る」自体が夜勤さんの言葉からの引用だけど、
> それも読んでないんだろうね。

読んだ記憶はあるんだが、俺解釈してた。
字面通りに受け取らないとダメねー


> 普通は評価前に仕様確定するようなやり方はしないけどね。

<a name=>の件は、正直、すまなかった。


…漏れはもともと煽りキャラ持ってないんだが、
ﾏﾀｰﾘキャラも持ってないので、疲れた…
(引用ばかりすると、十分煽りになりうるんだが)
…疲れたので、今晩はもう逝くよ…探さないでくれ…鬱だ氏のう

729 ：音楽侍 ◆NtVkSITE ：01/09/07 01:28

>>727
＞ボランティアの作業で、仕切る人間が口だけじゃまずいと思いますです。

ちょっと違うです。むしろ、全体を見られる人はコーディングしない方がいいです。
どうしても自分が動くと、いろいろ出ます。読めるけどかけない人の方が適任かと。

いろんなプロジェクト見てくださいです。
リーダーやマネジャーがコーディングを始めたプロジェクトは大抵納期間に合いませんです。
品質管理もままなりませんです。

>>728
相談と報告のキモチが良薬かと・・・

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

とりあえず、既出の不具合で未修正のもの。
キャッシュであぼーんされたレスが見える？(詳細不明)>>441
PATH_INFO時に間違えるとレス１しか表示されない>>624
かちゅ〜しゃ規制>>670
設定ファイル読みこみ時のオーバーフロー>>674
行末の空白削除>>723
それ以前は>>397だけど、どれだけ残ってるかな・・

その他、今気がついたもの。
批判要望板で最近よく出てくる
「このスレッド大きすぎます」への暫定対処として、
datファイルの大きさがある程度(最大値-16K位)を超えたら、
「もうすぐ読めなくなります。新スレの準備を。」の警告があれば親切かも。

あと、できるだけ設定ファイルから読みこめるようにして、
リメイクは不要にした方がよさそうだね。

731 ：デフォルトの名無しさん ：01/09/07 02:19

>>723さんは
「スクリプト関連要望統合スレッド 」
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=994071363
の人ですね。

732 ：730 ：01/09/07 04:48

改めてソースを見たら、既に>>674は修正されてた。氏にます。
他にも修正済みがあるかも。

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

これまで行った変更点をすべて列挙して、それぞれの目的と変更量とそのリスク、
転送量削減に対する効果、その他の効果などを一覧にまとめてテストケース作って
すべて再評価した上で改めて内容を吟味したらいかが？

テストサーバに置いてここの住人にテスト手伝ってもらうとかはできるっしょ。
仕様書はソースコード、って状況はやっぱりＰＧの自己満足モードで終わっちゃうよう。

734 ：デフォルトの名無しさん ：01/09/07 10:44

read.cgiに加えられている変更点は単純に２つに分類できる。
A)転送量・負荷低減のために行われるもの
B)機能を追加してより使いやすくするもの
そして、それぞれの変更点について、
1)導入する
2)導入しない
3)時間帯によって導入する
の３つの選択肢がある。
この３つのうち、1)か2)かを選択するようにしておくのは
#ifdefで切り分けるだけなので比較的簡単だが、
3)の形式は#defineで導入し、さらに時刻によって
処理を変化させなければいけないので、1)2)よりは面倒になる。
しかし、転送量や負荷の少ない時間帯に比較テストできるため、
「試しにやってみて結果を知りたい」場合に有効になる。
試した結果が、時間制限付にするか完全導入するかの判断材料になる。

というわけで、「この機能は時間制限つきで導入してみよう」という指針が
示されれば、必要な変更を施して仮導入してもよさそうな気がする。
さらに、外部ファイルで変更可能にしておけばさらに良かも。

735 ：デフォルトの名無しさん ：01/09/07 10:44

ブランチを設けるのは大賛成。
Linuxみたく、安定版と開発版とで仕切る人が別になるのも手だろう。
従事するメンバーを分けるほど人数が多いわけじゃないが。

当面、安定版は現行のVer5.12と同等の機能部を抽出し
不具合を修正したものをベースに、ある程度の機能追加をしたものになると思う。
「ある程度」がどの程度なのかは、まとめ役の人の裁量に従いたいが、
-DZLIBは以前から作ってある
-DCHECK_MOD_GZIPはあった方がいい
-DUSE_SETTING_FILEは柔軟性のために必要
等々、結構難しそう。
さらに、-DZLIB,-DUSE_MMAP等の「見栄えは変わらないが負荷低減を狙う機能」は、
早目に安定版にいれて、確定させてしまいたいところだ。

また、増えすぎた#ifdefの中で、Ver5.10以前の導入で問題出ていないものは
条件をはずしてしまっていいと思う。
個人的には-DLASTMOD,-DNEWBA,-DGSTR2は全然問題なし、
-DPREVENTRELOADも#ifdef無しで構わないと思うが、
意志決定はまとめ役の人の判断に任せるのが一番。
BadAccessの旧版にあるAccept-UAのリストなどは、
コメントとして残しておくのがいいかもしれない。
(気分的には、BadAccess中のReadOnlyなローカル配列はstaticにしたいなー)

あ、娘。さんは「オリジナルも残したほうが」と言ってるな。
だったら、採用をほぼ決定したものに対しては、
同じ１種類の#ifdefにしてしまったら、少しはわかりやすくなるかも。

736 ：デフォルトの名無しさん ：01/09/07 10:45

以下は名無し娘。さんのお手伝い・・・のつもり。

>#ifdef の字面と内容が噛み合わない部分

-DCUTRESLINKは、本当に#define名と内容が一致していない。
変更部のメインは最適化で、リンクの削除はオマケ程度な感じ。
方向としては、
・mmapがSHARED & READONLYで使えるようにBigBufferを読みこみだけに
・ファイル全体やレス全体を走査する回数を極力減らす
・そのために変換や空白削除、http://のリンク等を全て同時に行う
といったところ。
ただ、そのことにより内部で保持するデータ形式が変わってしまい、
他の部分への影響も出ている。
名目通りのCUTRESLINKに相当するのは大きなswitch文の一箇所だけで
全体のdefine名は、つけ直すならBUFFER_READONLYとか
NO_RES_NUL_TERMINATEとか、そんな感じに近いと思う。

>replace系の関数を最適化する方が

上とも関連するけど、現在、-DCUTRESLINKを指定すると
replace系は全く使われない。
現行のVer5.12等では、hlinkReplaceの中でdoReplaceが使われているが、
これもressplitter_splitの内部に吸収されている。
ソース中ではTYPE_TERIが定義されていない場合にsomeReplaceが呼ばれるが、
同等の変換は既にressplitter_split内部で為されているので、本来必要ない。

というわけで、-DCUTRESLINK(内容は違う)を採用する方針でいくなら、
replace系には目を向けなくてもいいと思う。
あえて不安材料を挙げれば、Ver5.1xでの稼動実績があるのが基本部だけで、
保持データ系式の変更やhttp://リンク、mmapとの併用、
これらでの実績が乏しい点があるが、今のところ
まともなdatを低負荷時に読んでいる範囲では、問題は出ていない。

逆に、-DCUTRESLINKを採用しない/条件等によっては機能をoffにしたい、
となる可能性があるなら、replace系の最適化には意味がある。
その辺の判断と指示はまとめ役の人にお任せしたい。

737 ：♯6411 ：01/09/07 12:17

>>734
細分してみた。

> A)転送量・負荷低減のために行われるもの

* 外部的に機能がほぼ変わらないもの

A0) 安全性の向上のみを目的としたもの(いわゆるバグフィクス)
A1) 転送量の低減を狙っているもの
A2) 転送量以外の負荷低減
A3) 単なる設計・構造・インタフェイス変更

> B)機能を追加してより使いやすくするもの

B0) 従来仕様と相反しない、独立した機能
B1) 従来仕様の不備を補完するもの
B2) 従来仕様の不備を再定義するもの
B3) 従来仕様と置き換わるもの

フォローきぼんぬ

738 ：♯6411 ：01/09/07 12:20

>>735
PREVENTRELOADは、まだなんとなく
潜在的な問題をはらんでるような気もしない
でもないんだか、杞憂だろうか?

739 ：♯6411 ：01/09/07 12:23

>>736
CUTRESLINKを再評価するのであれば、
名前付けなおしてさらに細分化するのがよろしかと。

あと、従来とまったく置き換わってしまうものに
関しては、モジュールを切り分けることを
前向きに検討した方がいい。

740 ：デフォルトの名無しさん ：01/09/07 12:33

>>730おつかれ。
ところで、提案していた

>批判要望板で最近よく出てくる
>「このスレッド大きすぎます」への暫定対処として、
>datファイルの大きさがある程度(最大値-16K位)を超えたら、
>「もうすぐ読めなくなります。新スレの準備を。」の警告があれば親切かも。

はたしかに良いな。

是非搭載してほしいところだが、夜勤さんは嫌がるだろうか？
（read.cgiの負荷増大につながるため）

741 ：デフォルトの名無しさん ：01/09/07 12:33

今CHUNKが強制になってる感じ?
#ifdefでCHUNKにならない従来型UIにする選択肢なくなってない?

742 ：723 ：01/09/07 13:22

>>731
そうです。

743 ：♯6411 ：01/09/07 15:34

ブランチ案

○リリースには明示的にリビジョンを設ける
ex) 5.12
今回は、どの辺から始まってるか微妙なので、
-r4.99あたりで始めるといいのでは。
夜勤さんから、本番に適用したバージョンを
もらい受けて、-r5.xx などとしてcommit
以降、Revision 4.99 が存在するとして説明。

○リリース候補(4.9.x.x)
プロジェクトマスター
(あるいはマスターから委任された人間)
のみがcommitできるブランチ。
cvs tag -b RC-4-99 のようにつくっておく。

○ワーキングブランチ(4.9.x.x.y.y)
今までheadでやってたものは、みなブランチの中で
作業を行う。
cvs co -r RC4-99 bbs で取り出したブランチに、
cvs tag -b HEAD-4-99 のようにつくっておく。

○プロジェクトマスターの役目
・適宜ワーキングを吟味し、RCに取り込み、commit
・夜勤さんの作業に追従
・新しいリリースが出たら、ブランチを作成。

○検討事項
ワーキングブランチは、
改造系統毎に分ける、あるいは
担当毎に分ける方がいいかもしれない。


ブランチの作成は、サーバ持ってる aki さん
あたりにやってもらえると早いんだけど、
さしあたっては名無し娘。さんがやってもらえれば。
(ローカルで念入りに実験した方がいいかも)
漏れがやってもいいです。

744 ：♯6411 ：01/09/07 15:37

>>743 最新リリースの入手に手間取るようだったら、
さしあたっては8/28 4:00(GMT)あたりのものを
「仮リリース」として据えるといいかも

745 ：音楽侍 ◆NtVkSITE ：01/09/07 15:54

検証班の作業も工程に入れて置いてください(^_^;)

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

ver5.12(夜勤さん版)のひとつ前に実動してたのって、verいくつでしたっけ。。。

昨日ちょっとだけ、試しにteriに入ってるread.cgiをいじめてみたら、zz_xx の
size制限がかなり厳しくなってるようで。zz_xx[20]になってるのかな。
たとえば http://piza2.2ch.net/test/read.cgi?bbs="></a> みたいなこと
やられると気持ち悪いからかもしれません。
こんな感じで、いろいろちょこちょこと夜勤さんが手直ししてくださってるのかも。

なんにせよ、一度夜勤さんにお出まし願った方がよさそうですね。
どのソースを元に、どういうとこから手をつけてくのがいいか。
などなど。

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

>>746
> なんにせよ、一度夜勤さんにお出まし願った方がよさそうですね。
さんせい

748 ：デフォルトの名無しさん ：01/09/07 20:49

>>746-747 そうですよね　とにかく運営サイドの誰かに度々ここに来てもらって
意思疎通ができないと　こちら側だけで突っ走ってもタダの骨折り損になりそうな
気がしますし

749 ：デフォルトの名無しさん ：01/09/07 22:39

>746
http://piza2.2ch.net/test/read.cgi?b=tech&k=998845501
の段階で zz_GetString が変わって、キーの先頭1文字しか見なくなりました。
たとえば
http://piza2.2ch.net/test/read.cgi?board=tech&kiji=998997848
のように書いても正しく読めます。

750 ：名無し娘。 ◆vP.bOZFQ ：01/09/07 23:20

>>747-748
機会があればお願いしてきます。
>>749
1文字判定もできますが、たとえば zz_ky は今でも20文字(19文字)を
格納しています(判定後、切り出された文字列。たとえば key=998997848 の
"998997848"部分)。
http://piza2.2ch.net/test/read.cgi?bbs=123456789abcdefgh
をリクエストしたときのエラーメッセージ中、下部「過去ログ倉庫」の
リンク先を見ると、何となく何をやっているかがわかります。

751 ：名無し娘。 ◆vP.bOZFQ ：01/09/07 23:21

>>750
...hまでじゃだめじゃん。
http://piza2.2ch.net/test/read.cgi?bbs=123456789abcdefghijklmnop
やると。。。ね。

752 ： ◆D69Zsbfg ＠夜勤 ★ ：01/09/08 20:33

どうも、お世話になっています。 > みなさん。
明日の未明(今晩)あたりに、登場しまーす。
で、最新版を組み込もうかなぁと目論んでいます。

よろしくお願いします。

753 ：音楽侍 ◆NtVkSITE ：01/09/08 20:57

おつかれさまです。

754 ：デフォルトの名無しさん ：01/09/08 21:04

ﾔﾀｰ

755 ：デフォルトの名無しさん ：01/09/08 21:42

......となると　どれを組み込んでもらうのか整理しておかないと

756 ：デフォルトの名無しさん ：01/09/08 21:45

#defineを消すだけでは外せない機能がありすぎ。やばいって。

757 ：デフォルトの名無しさん ：01/09/08 22:00

全然コード考えてないけど、この程度の条件分けは必要だろ。

/* "投稿日"を(時間帯によって)非表示にする */
#define CUT_DATE_STRING

/* テレホタイムに読みこめるdatの最大値 */
#define MAX_FILESIZE_BUSY

/* 大きすぎて読みこめなくなります */
#define CAUTION_FILESIZE

/* <a name=...> */
#define CREATE_NAME_ANCHOR

/* '<'や'&'の直前に、必要ならば空白をいれる */
#define CHARCHECK_STRICT

USE_PATHのサブに
#define OUTPUT_SUBBUCK
#define OUTPUT_INDEX

758 ：名無し ：01/09/08 22:05

さて、もうすぐ1000000000秒ですが、何か起きるでしょうか。
プログラムがこけたら笑えます。

もうすぐ1000000000秒　2chでもお祝いをしましょう
http://kaba.2ch.net/test/read.cgi?bbs=news&key=999927113&ls=50

759 ：デフォルトの名無しさん ：01/09/08 22:07

■　ひとあしお先に。
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=1000000000

760 ：デフォルトの名無しさん ：01/09/08 22:10

大きな問題は２点。

１．<a name=>が外せない
→単純にサイズが増える(総リクエストが減る可能性はある)
２．CHUNK_ANCHORが外せない
→>>nnnでリンクされる範囲が不要に大きくなる

２は、REWRITE_HREF2で一応回避可能。

761 ：デフォルトの名無しさん ：01/09/08 22:32

>>757
さっさとやろうかと思うんだけど、

/* "投稿日"を(時間帯によって)非表示にする */
#define CUT_DATE_STRING
これ時間帯判定いるのかな? いらないんでないかと思うがどうかな。

いらないのならr2chhtml.hだけで完結するんだが。

762 ：デフォルトの名無しさん ：01/09/08 22:34

>で、最新版を組み込もうかなぁと目論んでいます。

何が何やらぐちゃぐちゃなのでマズいんではないかと..

763 ：名無し娘。 ◆vP.bOZFQ ：01/09/08 22:34

>>752
それまでに現状をまとめとかにゃいかんなぁ。
とはいっても、最新版の状況は私もさっぱり(汗
>>758
bbs.cgiがtimeを見ているのですが、これもちょっと心配(w
知りうる資料では、if(time > xx)な比較の仕方をしていないのでだいじょぶそう。

764 ：デフォルトの名無しさん ：01/09/08 22:40

正直、最新版を組みこむのはもう一日待ってもらったほうが無難。

それより、夜勤さんに質問しておいたほうがいいと思う。
・datの最大サイズは、時間帯によって可変にした方がいいのか
・「大きすぎます」に近付いたら警告を出していいか
・ツールの差分取得(の圧縮)は、.htaccessで対応してもらえるのか
・○○な機能は必要なのか
・○○な機能を組みこんで良いか
等々。

765 ：名無し娘。 ◆vP.bOZFQ ：01/09/08 22:41

まず、.datをmod_gzipでgzip圧縮して転送する件、直近の夜勤さん情報。
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=996674822&st=267&to=268&nofirst=true

http://piza2.2ch.net/test/read.cgi?bbs=tech&key=981726544&st=856&to=859&nofirst=true
の意図は、.htaccessの記述によって mod_gzipを.datにも有効にしようという
ことのようですが、もしや .htaccess に記述しても無効なのでしょうか。
有効ならば、.htaccessに記述するだけで、.datも圧縮転送しますです。

もちろんread.cgiも.dat圧縮に対応しておけば（"?raw="）差分転送とかできて
うれしい（＾＾

766 ：名無し ：01/09/08 22:43

夜勤さんの多忙なので、今日しかチャンスは無いのだと思う。

767 ：761 ：01/09/08 22:48

とりあえず時刻判定なしで

/* "投稿日："を非表示にする */
#define CUT_DATE_STRING

commitしたっす

768 ：デフォルトの名無しさん ：01/09/08 22:51

>>763
>知りうる資料では、if(time > xx)な比較の仕方をしていないのでだいじょぶそう。
数値レベルで処理してるものは今回は関係ないよ。
文字列化するときに長さを9桁(以下)固定前提に処理しているものがあると
まずいってだけ。

769 ：デフォルトの名無しさん ：01/09/08 23:10

rewrite_href中、} else { をぶった切って、

#ifdefCHUNK_ANCHOR
　/* chunk仕様を生かすためのkludgeは以下に。 */
　mst = (st - 1) / CHUNK_NUM;
　mto = (to - 1) / CHUNK_NUM;

　if (mst == mto) {
　　/* chunk範囲 */
　　mst = 1 + CHUNK_NUM * mst;
　　mto = CHUNK_NUM * (mto + 1);
　} else
#endif
　{
　　/* chunkをまたぎそうなので、最小単位を。*/
　　mst = st;
　　mto = to;
　}

にすれば、CHUNK_ANCHORがdefineされていなくてもコンパイルは通るようになる

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

mod_gzip使うのなら
　　　　mod_gzip_item_include mime "text/.*"
でいいのではないかな？　あとserver-parsedの問題は
　　　　XBitHack full
とした上で　.htmlファイルのパーミッションを"g+x"にしてもらえば
Last-Modified吐くようになるし

771 ：デフォルトの名無しさん ：01/09/08 23:22

>>769
commitした

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

CREATE_NAME_ANCHORの変更点を捜索中・・・

r2chhtml.h内で
#ifdef CREATE_NAME_ANCHOR
　・・・
#else
それぞれ、パラメータのlはそのまま無視するようにして、書きなおす
CUT_DATE_STRINGとの関係で、さらにややこしいか？
#define R2CH_HTML_RES_MAIL(n, l, m, nm, d, t)
#define R2CH_HTML_RES_NOMAIL(n, l, nm, d, t)
#define R2CH_HTML_RES_SAGE(n, l, nm, d, t)
#endif

rewrite_href()内の
　/* 新しい表現をブチ込む */
　if (isprinted(st) && isprinted(to))
　{
　　d += sprintf(d,
　　　"<a href=#%u>",
　　　st);
　} else
を、
#ifdef CREATE_NAME_ANCHORで囲む

同、後半の
#ifdef USE_PATH
を
#ifdef CREATE_NAME_ANCHOR
に変える

必要なら、rewrite_href2()内の #ifdef USE_PATH で囲まれたif文の、
else までを #ifdef CREATE_NAME_ANCHORで囲む

out_html()内の、
pPrintfでフォーマットに
R2CH_HTML_RES_MAIL,R2CH_HTML_RES_NOMAIL,R2CH_HTML_RES_SAGEを用いている部分の、
全体を
#ifdef CREATE_NAME_ANCHOR
で囲み、
#else以下に、同じ内容でパラメータに２つあるlineNoを１つだけにしたものをつける
#endif

こんなもんだと思う。ただし、未検証（ごめん）

773 ：名無し娘。 ◆vP.bOZFQ ：01/09/08 23:39

>>768
それくらいは知ってますよん（＾＾
ちょっと知り得ないところからもtimeと比較する値が提供されているようだから、
念のためのお話。

774 ：デフォルトの名無しさん ：01/09/08 23:41

>>772
やってみる。ちょいお待ちを

775 ：774 ：01/09/09 00:07

>>772
あててみた。
動作確認も軽くしてみたけど、厳重なチェックとかよろしく

776 ：名無し娘。 ◆vP.bOZFQ ：01/09/09 00:11

何を考えるべきか混乱中。
まずはソースの整理＆可読性の回復かな。

まず zlib を試してみて、うまくいったら正式実装。ただし念のため、
簡単に強制的に gzip_flag = 0 できるようしておいたほうがいいかも。
そして、GZIP/ZLIB関連の#ifdefを整理。

bzip/deflateは考えないことにしてよいかな？
expire/cache-controlも考えなくていい？

CUTRESLINK関連は、imodeの使い勝手や関数の使用不使用と一部連動しているが、
これらを切り離した上で、1つの-DCUTRESLINK（CUTRESLINKするかしないかの
単純なもの）にまとめる。実装はしておいて、いつでも切り替えられるように
しておけばよい（設定外部ファイル化も実装できているのでいつでも移行できるし）。

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

>>776

778 ：777 ：01/09/09 00:16

操作ミスごめん。

>>776
>bzip/deflateは考えないことにしてよいかな？
bzipは考えなくて良いと思う。
deflateはzlibネイティブだし、HTTP/1.1に言及があるので将来的にはアリかな。

>expire/cache-controlも考えなくていい？
当面考えなくていいんじゃないかな。

779 ：名無し娘。 ◆vP.bOZFQ ：01/09/09 00:21

read.h に追い出されているものと追い出されていないものって、
何か戦略的な区別あります？
一度このあたり整理した方がよいかも。
# ソース読んできます

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

外部的に変化のないcondition消さない?
REWRITE_HREF2とかNEWBAとか。

781 ：♯6411 ：01/09/09 00:30

今起きた…

>>769
>>775
すまんこってす。

>>779
read.h は、read.c における
外部インタフェイスとして切り分けた。

782 ：名無し娘。 ◆vP.bOZFQ ：01/09/09 00:54

>>778
よくみたらexpiresって実装されているんですね。どうしましょう。。。
すぐに正式作用できそうならしちゃってもいいかと。
>>780
GSTR2 も消してよさそう。従来型との互換はあるので。
COOKIE もとりあえず消しちゃって、お蔵入りじゃダメでしょうか。
condition多すぎて読むのがつらいです。
>>781
了解です。

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

>>782 Expiresについては>>679参照　少なくとも転送量を増やすことはあっても
減らすことはないと思われ

784 ：名無し娘。 ◆vP.bOZFQ ：01/09/09 01:05

あと、replace系はすべて破棄して、その分、CUTRESLINKする/しない場合の
>>xxx へのリンク設定部分を最適化ってことでよさそうですね。

…なんてことを考えていたら、むしろ絶対URI表記にリンク設定(<A>タグ)
しないことの方も考えていいような気がしてきた。この部分は.datに<A>タグ
ないものをread.cgiでわざわざはっているのだけど、絶対URI表記はコピペ
すればそのまま飛べるんだし。どうでしょう？

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

>>780
USE_INDEX2CGIは、いまさら不要です。

>>775
CREATE_NAME_ANCHORなしでテストしたら、
>>60が、
　read.cgi?bbs=tech&key=998695422&st=51&to=100&nofirst=true
　read.cgi/tech/998695422/51-100
になるんですが、これでいいの？
従来仕様(st=60&to=60&nofirst=true)は考えないでいいの？

CHUNK_ANCHORで、"&n=t"ってなっているけど、nofirst=trueと混じっちゃって
キャッシュが効きません。
bbs.cgiとのからみがあるから、n=tとnofirst=trueを簡単に統一できる手段が
欲しいな。

786 ：775 ：01/09/09 01:15

>>785
それはread2ch.hにコメントで書いたけど、CHUNK_ANCHORもコメントアウトすれば目的の番号だけの
参照になるんだよな。
CREATE_NAME_ANCHORなしでCHUNK_ANCHORありってのはそもそも矛盾してるよね?
頭で条件つぶしかけるべき?

787 ：775 ：01/09/09 01:18

>>785
>CHUNK_ANCHORで、"&n=t"ってなっているけど、nofirst=trueと混じっちゃって
>キャッシュが効きません。
この点単純に修正してcommitしてみた。

788 ：名無し娘。 ◆vP.bOZFQ ：01/09/09 01:18

>>783
了解です。expires部分もいったんソースから消してしまいましょうか。
>>784
補足。read.cgiでの動作を以下のようにしてはどうかなという提案です。
LIMIT_PM - LIMIT_AM：>>xxx のリンク削る。
LIMIT_AM - LIMIT_PM：http://... ftp://... のリンクはる。

read.cの最後4つの関数 cutWordOff,ExistHlinkX,ExistHlink,hlinkReplaceは
#ifndef CUTRESLINK してしまってよいようです。

789 ：772 ：01/09/09 01:20

>>775
お疲れさま。
rewrite_hrefの後半の書き換え、>>772に書いた通りじゃまずいって後で気がついたんだけど、
直してくれたんですね。どうもです。

今、夜勤さん向けにread2ch.hよりちょっとだけ詳しい機能説明書いてます。
勝手にON/OFF推奨してるんで、そのへんの判断がおかしかったらツッコミお願い。
もうちょっと時間くださいな。

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

>>782
>>783
>>788
EXPIRESは氏んでるってば
まあ役に立つものではないので
ソースから削るのを止めはしないけど
（これって6411氏が入れたんだっけ？）

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

ひとつひとつ。
>>788

>read.cの最後4つの関数 cutWordOff,ExistHlinkX,ExistHlink,hlinkReplaceは
>#ifndef CUTRESLINK してしまってよいようです。
これ当てました。

792 ：名無し娘。 ◆vP.bOZFQ ：01/09/09 01:33

>>790
ええ、氏んでるかどうかではなく、ソースから削っちゃうかどうかを。

793 ：772 ：01/09/09 01:36

REWRITE_HREF2削除した。

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

imodeの時に、最初から（st=1&to=10）の時だけ[次の10レス]が出ません。
なんか、nofirst=true相当になっている感じ。

795 ：名無し娘。 ◆vP.bOZFQ ：01/09/09 01:41

>>794
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=999099427&ls=20
この問題かな。。。ずいぶん昔からですね。

796 ：説明がき−１ ：01/09/09 01:41

有効なオプションの説明
◎Ver5.1xで導入済み
○Ver5.1xで導入済みだが、変更あり
△新機能・大きな変更ではない等で、ON推奨
▲新機能・変更が大きいので、とりあえずOFF推奨
×新機能・テスト中等の理由で、開発版でもOFFになっているもの

○CUTRESLINK
ファイルのreadとsplitを最適化する
(define名がおかしい)

○LINKTAGCUT
混雑時間帯に >>000 形式のレスへのリンクを削除。
「レスを全部読む」の増加への対策として、
表示範囲外のリンクは削除しないように変更。
(CUTRESLINKが有効な時のみ機能する。0/1で指定)

△RELOADLINK
一番最後に、「更新したレスを表示」のリンクを表示する
連打されてもNotModifiedが返るので、大きな負荷にはならないはず。

◎LASTMOD
導入済み。ほぼ必須。

×EXPIRES
proxy用に、キャッシュの保持期限を出力する。

◎NEWBA
BadAccessの新しいバージョンを使う。
稼動中。今のところ問題なし。かちゅ〜しゃ規制に注意。

◎GSTR2
nofirst → n など、短縮形で指示できるようにする
稼動中。今のところ問題なし。

▲USE_PATH
PATH_INFOを処理することにより、
http:://piza2.2ch.net/test/read.cgi/tech/998997848/10-20
のリクエストを処理できるようになる。
CHUNK_ANCHORとの併用で効果を発揮する。
http:://piza2.2ch.net/test/read.cgi/tech/
時に、板のスレ一覧を表示するため、負荷が増える可能性あり。

×COOKIE
Cookie による名前、E-mail フィールドの初期値の埋め込みを CGI 側で行う
Last-Modified付加により、proxyでキャッシュされた場合に各種の不都合
(最悪の場合、キャップ・トリップのパス漏れ)が発生するため使用不可に

797 ：説明がき−２ ：01/09/09 01:42

◎PREVENTRELOAD
書き込み直後のリロードを防止する
FORCE_304_TIMEで指定された時間の間、304 Not Modifiedを返す
稼動中。

◎GZIP
△ZLIB
出力を圧縮する。
ZLIBを指定すると圧縮にgzipを使わなくなるため、
プロセス数が減り、負荷低減につながる。

△RAWOUT
datの(差分)取得をread.cgiで処理する。
生datも圧縮して転送量を減らすことができる。
CGIへのリクエストが増加する可能性があるので、負荷が大きくなる可能性あり。
mod_gzipの設定次第では、不要になる場合も。

△USE_MMAP
fread(read)の代わりにmmapを使用する。
負荷の低減が期待できる。

×EXPLICIT_RELEASE
明示的に資源を解放する。
CGIプロセスが終了すれば、資源は解放されるので明示的な解放は不要。
逆に、解放処理が負荷を増加させる危険があるので、OFF推奨。

×USE_INDEX
read.cgi側によるindexの実装(experimental)
/board/dat/idx/ディレクトリがあれば、各レスのindexを作成する。

×ALL_ANCHOR
▲CHUNK_ANCHOR
トップに「全部読む」/CHUNK_NUM毎に区切ったレスへのanchorをつける
どちらかはあった方がよさそうだけど、
CHUNK_ANCHORには、現在、副作用があるので。
※表示範囲外への >>000 形式のリンクを、１レス分であっても
CHUNK_NUMレス分へのリンクに変更してしまう。

△LATEST_ANCHOR
「最新レス LATEST_NUM」をつける

798 ：説明がき−３ ：01/09/09 01:42

▲SAGE_IS_PLAIN
sageレスのとき、名前を太字にしない
(<a href="mailto:sage">の代わりに<font color=>をつける)
若干転送量が減るが、見た目が変化する。

×USE_INDEX2CGI
index2.cgiがあったら、「掲示板に戻る」のリンク先をindex2.cgiにする
もはや不要？

△CHECK_MOD_GZIP
mod_gzipが導入されていたら、「掲示板に戻る」のリンク先を
/板名/ にする。
(OFFにすると、戻り先はaccept-encodingによって、/index.htmか/index.htmlになる)

△CUT_DATE_STRING
"投稿日："を非表示にする

▲CREATE_NAME_ANCHOR
各レスにアンカーをつける。
CHUNK_ANCHORとの併用でキャッシュ効果が上がる可能性があるが、
転送量を増やす結果になる可能性もある。
これをOFFにした場合でも、CHUNK_ANCHORをOFFにしないと、
>>000 形式のリンク先が広範囲となるため、
転送量を増やす可能性がある。

△USE_SETTING_FILE
板毎に設定が書いてあるファイルを使用する。
板のディレクトリにSETTING_FILE_NAMEのファイルがあり(SETTING.TXTと同じ場所)、
有効なエントリがあれば、デフォルト値を置き換える。
SETTING_R.TXTは
---
FORCE_304_TIME=30
LIMIT_PM=23
RES_NORMAL=50
MAX_FILESIZE=512
LINKTAGCUT=0
---
など。空行可。'='前後の空白不可。'='がなかったり、マッチしなかったりしたら無視
最後の行に改行が入ってなかったら、その行も無視
現在設定可能な値は、
RES_YELLOW
RES_REDZONE
RES_IMODE
RES_NORMAL
MAX_FILESIZE (Kbyte単位で設定)
LIMIT_PM
LIMIT_AM
FORCE_304_TIME (PREVENTRELOAD有効時のみ)
LATEST_NUM (LATEST_ANCHOR有効時のみ)
LINKTAGCUT (CUTRESLINK有効時のみ)

799 ：775 ：01/09/09 01:45

あ、>793 は私。名前書き間違えた

800 ：796-798 ：01/09/09 01:47

説明がき書いている間に、すでになくなってしまったものがいくつか・・・
ON推奨/OFF推奨は俺の主観なので、他の人の意見も聞いて、
合意のうえで夜勤さんに提案したいな。

333KB

---

新着レスの表示

---

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

0ch BBS 2004-10-30