bbs.cgi 改良案スレッド

このスレッドでは、現行の bbs.cgi の改良案、及び、次世代 bbs.cgi の
検討を行います。
但し、現行の bbs.cgi が公開されることはありません。
それを前提に、できることをご検討下さい。

他の話題は、それぞれ以下のスレッドへお願いします。

●２ちゃんねる開発統合スレッド（連絡用スレッド）
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=998908559&ls=20

●キャッシュ型負荷分散システム開発スレッド
http://cocoa.2ch.net/test/read.cgi?bbs=unix&key=998908154&ls=20
　◆キャッシュ型負荷分散システムの概観
　http://piza2.2ch.net/test/read.cgi?bbs=tech&key=990334284&ls=20

●プログラマが2chを救う！？２（read.cgi開発スレッド）
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=998845501&ls=20

●スキルの高い方知恵を貸してください2号（HTMLの整形、軽量化）
http://natto.2ch.net/test/read.cgi?bbs=hp&key=998774537&ls=20

●2chの動作報告はここで。（動作報告・障害報告スレッド）
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=998808733&ls=20

●２ちゃんねるWikiとTiki（全体にわたる参照事項です）
http://www.gedoh.org/aki/2ch/wiki/yukiwiki.cgi?TopPage
http://www.gedoh.org/aki/2ch/tiki/

◆各種ソースコード最新版
http://star.endless.ne.jp/users/forcount/4countbbs/scriptmaker/index.html

cgiの出来は変わらないのに、
ここ2日位人口が少ないねえ。
この原因を解析する方が実収入に直結するよ。

>>2
いみがわからないっす。
主語がないっす。

引っ越してきました♪
とりあえず、仕様修正案をまとめてみませんか?

漏れが把握してるもの、ちうか漏れが言い出しっぺのもの;
・あぼーんの固定レコード化
- あぼーん時刻を書き込んでもらう
- 特定のフィールドをあぼーんがわかる状態にし、
あとは「あぼーん」を書き込む、さもなくば
whitespaceで塗りつぶす。
・投稿日のフィールドに、秒を含めた方が、使いでが
あるかもしれず。Last-Modified粒度を上げるため。
(read.cgiで出力する際に削るのは可)

…曜日は復活きぼんぬ

>>2 >>3 ｲﾊﾟｰﾝ人のことを指してると思われ。
トップページの豹変など、
使い勝手が変わってることにまごついてると思われ。
…ちうか漏れの常駐板が�d�j…

確かに、変なマークを使うより、現在の日付フィールドを使用した方が
現行のフォーマットに沿った扱いが出来るから、良いかもしれない。

年のフィールドは１年以上前のレス以外非表示でイイと思う
つか過疎板で上げ荒らし食らわない限り表示の意味無いし

bbs.cgiをアプレット化してクライアント側で
フローティングスレッドを実装するってのは駄目？

>4
Last-Modifiedは、ファイルの更新日時を使うから、特に投稿日フィールドに
含める必要は無いと思う。

曜日は……向こうのスレで相談しましょう。

>>9
曜日はここでいいんですよ。bbs.cgiが.datに吐いていますから。

負荷の話なのでオフトピ

100レス書き込まれる毎に、その分gzipかけちゃうのはどうでしょう？
先頭100レス、次の100レスと行くならHit率高そう
要read.cgi対応

>>9 L-Mは、部分出力する際に、
「指定範囲の最後の(あぼーん含む)日時」に
した方が、キャッシュ串などとの相性が
よくなると思われ。というわけで提案してるのです。

いま、範囲指定L-Mのあくどい(効果的な?)
使い方を考えてます。まだ思考実験の段階ですが。

>10
あ、ホントだ。datから消えてる。ということは、誰かがbbs.cgiをいじったのか。

>>11 いまのところCPU負荷が取りざたされてない
っぽいので、CPU負荷が無視できなくなった
時点で考えてもよろしかと思われ。

>>13 曜日が消え失せたのは日曜の早朝からでは?

"レスを全部読む 最新レス５０ レス１−１００"を"レスを全部読む レス１−１００
最新レス５０"の順にして、100レス規制中はアンカータグ一つで括ればURL分削れます
またどちらかのリンクを削るのもアリじゃないでしょうか？

曜日は残した方がいいと思う。
年も、下二桁残したほうがいいんじゃないかな。googleで引っかけたりした
時に年が分からないと不便だし。
同じ理由で[掲示板に戻る]も残して欲しいけど、これはread.cgiだよね。
…てゆーか、根本的にすれ違いな気が(;´д`)

言いたいことは、曜日や年などの基本的情報は残して欲しいってことです・・・。

read.cgiやdat直読みブラウザとのかねあいもあるけど、
datのフォーマットを根本から見直しちゃダメ？
日付なんてepochからの通算秒で保存しておいて
read.cgiの方で変換して出力でいいと思うんだけど。

http://teri.2ch.net/test/read.cgi?bbs=accuse&key=998903558&st=681&to=681
「２　mod_gzipに関しては、交渉難航中（対Hurricane Electric） 」
らしいからdatのgzip化を考えた方がいいんじゃない？

レスを全部読むを無くせば、というのは思いっきりガイシュツ？

>>20
read.cgiの方でｶﾞｲｼｭﾂです。

お笑い小咄板は消したほうがいいかもしれないな。なんとなく。

せっかくだから、このスレにも貼ります。あと、ちょと変更。

次世代？2ch .datとread.cgi、その他関連ファイルの仕様案 その２

【その１からの変更点】
・マークの取り扱い、セパレータを変更するのではなく、日付フィールドに
　それを納めるようにする。
・その他、色々（主に独り言）と追加。

【要点】
・bbs.cgiがインデックスファイルを作成すること
・削除処理は、レス内容塗りつぶしで行い、datのサイズを変えないこと
　（削除処理でインデックスファイルを更新しない様にするため）
・削除処理の履歴をdatファイルに記録すること
・datそのものの差分を取得するcgiを作成すること
・現行のdatファイルの仕様から*なるべく*逸脱しない。「かちゅーしゃ」
　等の専用UAとの親和性も考慮すること。

◎インデックスファイル
インデックスファイルは、bbs.cgiが各レス書き込み時に、書き込み後の
datファイルのサイズを記録し、レス番号と関連付ける。
たとえばレス番号nのレスを読み出したい場合は、datファイルより、
idx[n-1] 〜 idx[n] - 1 の範囲を読み出す。
ファイルフォーマットは未定。32bitバイナリのベタファイルで十分だと思う。

◎マーク文字列
datファイルの日付フィールドをレスの種別を示すためのマークとして
使用する。日付フィールドは最低１４バイト確保されるものとし、その中に
特定の文字列を書き込む事により、種別を設定する。
例：
「01/06/23 21:26」　　通常レス
「DEL+9999999999」　　削除レス（"DEL+" + time_t）
「DEL*9999999999」　　削除履歴（"DEL*" + time_t）
「STOP」　　　　　　　スレッドストップされたスレッド

◎削除処理
削除スクリプトは、該当レスの内容を'#'で 塗りつぶすことで、削除処理
を行う。datファイルのサイズを変更しない。
（インデックスファイルの整合性を保つため）
また、datファイル内の日付フィールドを「削除レス用マーク文字列」で置
き換える。ただし、フィールドの長さを変更しないように、マーク文字列
の後はセパレータまで'#'で埋めること。
また、datに通常のレスの形式で、削除履歴を記録する。名前フィールドは
削除されたレス番号とし、日付フィールドは「削除履歴用マーク文字列」
とする。

例：３件書き込まれた後、２が削除、さらに１件書き込み。
----------------------------------------------------------------------
名無しさん<>sage <>01/06/13 21:26<>暴露しろや、ｺﾞﾙｧ <>
##########<-#####<>DEL+998845501#<>########### <>
名無しさん<>sage <>01/06/13 21:36<>↑削除依頼出しときました。 <>
2<><>DEL+998845501#<>
名無しさん<>sage <>01/06/13 21:46<>お、早速あぼーんされてる <>
-----------------------------------------------------------------------

◎dat差分取得スクリプトreaddat.cgiの作成
専用UAやミラーサーバがdatファイルを取得する際に使用する。
ただし、取得する際にはdatファイル内に記録された削除履歴を含めて取得する
こと。たとえば上記のdatファイルの場合、st=3&to=4 を取得する場合、実際に
取得されるのは、３行目から５行目、「↑削除依頼」から「お、早速」まで。
また、上記のdatファイルからレス番号４のみを取得する場合は、４行目と５行
目を取得する。（削除履歴を間違いなく取得させること）
専用UAは、取得した差分datから、削除履歴をみて、既に取得しているログの
削除処理を行うこと。 （もしくは該当レスの再読込を行うこと）

◎read.cgiの変更点
・dat_read()ではdatファイル全部を読み込まず、インデックスファイルに基づいて
　読み込む。
・マーク文字列を認識する。通常のレス、削除されたレス、削除履歴を認識すること。
　削除履歴は、read.cgi内で「あぼーん」として表示するようにする。

◎問題点
・「透明あぼーん」に対応できない。マーク文字列を"DEL%"等として透明あぼ
　ーんと認識させることは可能。
・堅牢性　現行の堅牢性にはかなわない。インデックスファイルとdatファイルとの
　整合性がとれなくなった場合、困ったことになる。ただし、不整合はread.cgi
　内で完全ではないけど検出可能。read.cgi内でインデックスファイルの再構築
　を行っても、それほどの負荷にはならないと思う。
・既にUA内に取り込まれたスレに、削除処理がなされた場合、誰かがそのレスに書
　き込まないと、「あぼーん」を認識できない？（UAの仕様にもよるか。datファ
　イルのサイズをみて新規レスを認識するUAなら、大丈夫か？）

◎そのほか
・日付フィールドはtime_tでもいいと思う。その方がLast-Modifiedをきめ細かく
　出力できる。この場合マーク文字列は、負の値を用いて認識するとか。
　ただし、read.cgi、専用UAの変更が必要。
・datファイルをユーザから見えないようにしてしまおう。（無謀？）

dat差分取得スクリプトの名前はofflaw.cgiにすることを提案。

曜日については datに書いておく必要はないのでは？
必要なら read.cgi側で作成すればいいんだし　

一応説明しておきます。

・インデックスファイルの作成
主目的はread.cgi、readdat.cgiの軽量化。そもそも軽いに越したことはない。
また、この先ミラー化とかが進むのであれば、どんな環境で動作させることに
なるかか分からない。現行の、1レス取得でもdat全部をなめる、という方法で
は負荷が高すぎる。

・削除処理をレスの塗りつぶしで行う
インデックスファイルを作成するなら、その整合性を少しでも保つため、dat
ファイルは単調増加であることが望ましいから。大きいスレッドを処理する際に、
ファイルアクセスが減る。

・readdat.cgiの作成
専用UAの仕様を推奨したり、ミラー化が進むのであれば、必須の機能。また、
この機能を作成すれば、datファイル自体をユーザから隠すことも可能。

・datに削除履歴を残す
readdat.cgiを使用する場合に、削除処理が行われたことを専用UAが認識する
ために必要。

・日付フィールドをtime_tに変更する。
きめ細かいLast-Modifiedを出力するためには、必要。

　こんなところかなあ。あ、もちろん、全ての名称は（仮）です。

＜間違い訂正＞
例：３件書き込まれた後、２が削除、さらに１件書き込み。
----------------------------------------------------------------------
名無しさん<>sage <>01/06/13 21:26<>暴露しろや、ｺﾞﾙｧ <>
##########<>#####<>DEL+998845501#<>########### <>
名無しさん<>sage <>01/06/13 21:36<>↑削除依頼出しときました。 <>
2<><>DEL*998845501#<>
名無しさん<>sage <>01/06/13 21:46<>お、早速あぼーんされてる <>
-----------------------------------------------------------------------

>>23
> ・bbs.cgiがインデックスファイルを作成すること
datが半固定レコード化されるだけでもけっこう
効率化につながるとの思考実験結果が
出ておりますので、indexは後回しでもよろしかと。

> ・datそのものの差分を取得するcgiを作成すること
これはさくっとread.cgiに組み込んでしまうのが早いか?

> ◎インデックスファイル
read.cgiで生成してしまうという選択肢も考えられ。

> 「DEL+9999999999」　　削除レス（"DEL+" + time_t）
> 例：３件書き込まれた後、２が削除、さらに１件書き込み。
> ----------------------------------------------------------------------
> 名無しさん<>sage <>01/06/13 21:26<>暴露しろや、ｺﾞﾙｧ <>
> ##########<-#####<>DEL+998845501#<>########### <>
> 名無しさん<>sage <>01/06/13 21:36<>↑削除依頼出しときました。 <>
> 2<><>DEL+998845501#<>
> 名無しさん<>sage <>01/06/13 21:46<>お、早速あぼーんされてる <>
> -----------------------------------------------------------------------
あぼーんレコードは、「通常カキコとして取り込んでも
どうにか認識できる形」にしましょう。
例> <><>01/06/13 21:40 あぼーん<>あぼーん(以下埋め草の0x20)<>
通常、ID:???が入ってるとしたら、「あぼーん」を
挿入することによってレコードサイズがオーバーする
ことは、けっこう考えにくい。ID:が8文字入っていれば
確実にレコードサイズの確保が保障できる。
どうしても確保できなさそうなときは、「ｱﾎﾞｰﾝ」を使う
というのはどうだ?(ｗ

削除履歴に関しては使いやすい仕様なのかどうか
れびう中。

>>26 現時点で、投稿日フィールド(ID含む?)を、
そのまま解釈せずに使用している処理系が
多いと思われ。read.cgiに生成させるのは可能。

>>27
日付フィールドは、秒まで入れてもらうだけで、
構わないような気がしたり。
time_tは、その方が楽だという実装側の都合だし(ｗ

ディレクトリ構成は今まで通り？
.datファイルと、htmlファイルの両方を吐き出す？
開発言語は？C？perl？

インデックスファイルをread.cgiで作成するってのは、
一つの手ですね。datが更新された直後に呼び出された
read.cgiが自動作成する（インデックスを作り直す）様に
すれば、現在のread.cgiにも実装可能か。書き込み回数より
読み込み回数の方が圧倒的に多いはずですから、作成の負荷は
ちょっとかかりますが、読み込みの負荷は減るはず。
とりあえずの実装、実験としては十分かも。

＞あぼーんレコードは、「通常カキコとして取り込んでも
＞どうにか認識できる形」にしましょう。
おそらく専用UAは、投稿日フィールドを特に解釈せずに取
り込んでいると思いますので、これでも一応読み込めるはず
だと思っています（憶測ですが）。変な数字が表示されるの
は、それは我慢して貰うということで。
あと、IDですが、現在の「全板強制ID」が本当に続くのか、
いずれ緩和される可能性も考えておくべきかと。よって最小
１４文字、ということで、４文字のコード＋time_t(10bytes)
というフォーマットを考えてみました。（「あぼーん」と入
れたかったのですが、入らないので「DEL」と。）

個人的には、投稿日フィールドはtime_tで統一した方が、
いいと思ってます（周りのことは考えず(w ）
年を出すとか、曜日を出すってのはread.cgi、専用UAに任した
方がプログラムを作る方としては楽ですね。本来datファイルは
ユーザが見る物では無いわけですし。

>31
今のところ、そこまで踏み込むつもりは無いのですが、なんか
アイデアあります？

>31
開発言語は、現在のread.cgiがCですので、Cが妥当かな。

>>32
インデックスファイルを作成してread.cgiで読み出し範囲を簡単に指定できるなら、
htmlファイルを吐き出す意味がないと思います。
作成しないようにしたほうが、ファイルI/Oが減るので良いかと。

現状のカチュなどに対応を考えるならディレクトリ構成などは変更できないと思います。

perlならデバグぐらい応援できるかなと思っただけで。
素人考えでｽﾏｿ。

透明アボーンはレス番号がずれる欠点があったが、ずれないようにしてくれ。
あと、インデックスファイルには最新のn件取得を行う為に先頭に
現在の件数を入れておいた方がいいと思う。
# インデックスファイルサイズ / １レコードサイズでも求められない事はないが

参考
曜日有 ID無形式
<b>デフォルトの名無しさん</b>,sage,2001/08/09(金) 20:53, 本文,

現在の形式
<b>デフォルトの名無しさん</b>,sage,01/08/28 12:11 ID:xxxxxxxx, 本文,

datをアポーン固定にするなら、
IDXファイルを作るより、 datの先頭にインデックスを置いた方がいいんじゃないの？
レス50番毎に１個インデクスを作って20個分もあれば十分高速にならない？

>>37
そんならdatファイル先頭に最大発言数固定(1000?)にして
インデックスまるまる入れるとか。

透明でレス番がずれるのは証拠隠滅を連発されないようにする効果も
見込んでるから採用の見込みは薄いと思われ…

>>38 それでもいいんだけどね。
　すると書込みが発生する都度 インデックス部も書き換えられるから嫌じゃないかなと

DATの先頭に現在のレス数と、インデクスを５０番毎とか２０番毎程度に更新しといた方
がバランスがよさげに思えたから

>>39
> 透明でレス番がずれるのは証拠隠滅を連発されないようにする効果
証拠隠滅をされないようにするには例えば39が透明アボーンされた場合
　　38 名前：デフォルトの名無しさん
　　40 名前：デフォルトの名無しさん
みたいに名前の左にある連番をそのままにしておけばレス番もずれないし
透明アボーンされたこともわかるから証拠隠滅もされない

DATの先頭に現在のレス数と、最終更新日を書き込めば。
アボーン、透明アボーンがあった場合、最終更新日と、数字を書き込めばどうかと。

例1
200<>2001,8,28,13:20:10<>
名無しさん<>sage <>01/06/13 21:26<>暴露しろや、ｺﾞﾙｧ <>どうじゃｺﾞﾙｧ

２００のレスがあって最終更新が2001年8月28日13時20分10秒に最終更新あり。

例2
200<>2001,8,28,13:20:10<>abon
名無しさん<>sage <>01/06/13 21:26<>暴露しろや、ｺﾞﾙｧ <>どうじゃｺﾞﾙｧ

２００のレスがあって最終更新が2001年8月28日13時20分10秒に最終更新あり。
最終更新は、レスの中のどれかがアボーン

例3
200<>2001,8,28,13:20:10<>toumei
名無しさん<>sage <>01/06/13 21:26<>暴露しろや、ｺﾞﾙｧ <>どうじゃｺﾞﾙｧ

２００のレスがあって最終更新が2001年8月28日13時20分10秒に最終更新あり。
最終更新は、レスの中のどれかが透明アボーン

DATの先頭に書く場合最後の,の後に書いた方がカチューシャとかとの互換性上いいかもしれない

数字と英大小文字だけ使う62進数で書いた場合
2桁で 3844 レス数を表現するのには十分
4桁で 14M インデクス（バイト位置）を表現するのに十分

このインデックス部に書く年月日もこのさい62進数表現を使って YMDhms と６バイトにしたらどう？
Yは2062年にはまた0に戻る事にして

あと削除があった場合はリンクリストにするのはどうだろ？

idx埋込datファイル案：

先頭に埋め込むのは案外厄介かもしれないのでこういうのはどうでしょう

【各々レスに埋込案】
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,nnmmpppqqqq
nn は62進数２桁でこの行のレス番号を記録
mm は62進数２桁でこの行のバイト数を記録
pppは10レス前の相対バイト位置を62進数3桁で記録
qqqqは50レス前の相対バイト位置を62進数4桁で記録

これなら追記書込みだけで済むし、レス番指定されても
高速に検索出来ると思います

あぼーん時にdatを詰めるんじゃなくて、同じサイズで塗りつぶすようにするなら
あぼーん時に後続のインデクスを書き換える必要はない。
消されたレスのインデクスだけマジックナンバーで上書き。

>>45
１レコード分は必ず解析しなきゃいけないのね…
現行からの緩やかな移行を考えるなら仕方がないか…

いや、後ろから1+2+2+3+4　バイト読み込んで先頭が","で残り全部が英数文字だったら

そっから１レス前、10レス前、50レス前には一挙に飛べるからだいぶ高速になると思うんだけど？

>>41
さんせー
つか番号のギャップでアボーンされたこともわかるから、
アボーンと透明は一緒にできるんじゃないかな？
アボーンだけのレスを出力するより、転送量でもメリット大きいし

>>48
.dat異常や非同期読み込みに対応することを考えると
ケツから検索して'\n'があったら2+2+3+4+1読み込みでいいのでは？

さらに考えると、追加書込が同時に２つ行われた場合、
排他処理が巧く動かないとズレてしまう可能性があります
追加書込みした後、再度読み返して他のレスが書かれて
しまった場合は自分の責任で書き換えたとしても、その間
に読み出しが発生すると悲惨な事になりえます。

そこで、 >>45 を
nn は62進数２桁でこの行のレス番号
mm は62進数２桁でこの行のバイト数
pppは10レス前の絶対バイト位置 (adr10 % 238328) 62進３桁で記録
qqqqは50レス前の絶対バイト位置 を62進数4桁で記録
とします。
^ はベキ乗記号として
最終ファイルポインタから adr - (62^3) + ( ppp + (62^4) - adr) % (62^3)

つまり、もしかすると１０レス前でなく１１レス前かもしれない
けど、この方法なら書込み直後に誰かが読んでしまった場合でも
とりあえず余分に１レス読まれるだけの被害で済みます
なお、read.cgiでは最終行のレス番は間違っている可能性がある
として、１０レス前から連番をフリ直す事にします

TCPは使わないで、UDPでなんとかする。

＞５０
非同期的動作を考えると　インデクスデータ部にはなんかのチェックがやっぱり必要ですね
さらに１バイト追加してチェックサムに使うとか

チェクサムがわりは'\n'で代用できると思われます
非同期書き込みは実装しようがないでしょうから

>54
　いや　旧ファイルとの互換性を考えると本文がちょうどその文字数で
　全部半角英字の場合があるというのを忘れていました。

　チェックサムでも取り除けないですね。
　やっぱりありえない文字を含めないとダメかも

途中で書き込んでしまた>>54
つまり現在のファイルポインタよりmm＋１バイトが'\n'なら正常とみなすってことです
nn,ppp,qqqqも同様にチェックできるけど、どの程度までチェックするかですね

>56 なるほど　そのチェック方法ならそれほど負担じゃないですね

他の案として
　１） 文字 "" でインデックス部を囲む 　×バイト数が増えてしまう
　２）　nnバイト手前から "," カンマの数を数える　×処理が重くなる

とか考えてたけど、単純に mm+1 バイト前が \n かどうかで十分ですね

datファイルの書式

【各々レスに埋込案】
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,nnmmpppqqqq
nn は62進数２桁でこの行のレス番号を記録
mm は62進数２桁でこの行のバイト数を記録
pppは10レス前の相対バイト位置を62進数3桁で記録
qqqqは50レス前の相対バイト位置を62進数4桁で記録
現在のファイルポインタよりmm＋１バイトが'\n'なら正常とみなす

って事ですな。

いや
ppp 　は10レス前の絶対バイト位置 % (62^3)
qqqq　は50レス前の絶対バイト位置


と変更して下さい

datファイルの１行目は、本文の次のフィールドが、スレッドタイトルに
なっています。そこだけ注意が必要ですね。

bbs.cgiは、Perlで書いた方が良いのでは？
もしひろゆきが2ch管理人として活動を続けるという前提ですが。

#ひろゆきはCはできないらしいし

datファイルの書式

【各々レスに埋込案】
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,スレタイトル,nnmmpppqqqq
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,nnmmpppqqqq
nn は62進数２桁でこの行のレス番号を記録
mm は62進数２桁でこの行のバイト数を記録
ppp 　は10レス前の絶対バイト位置 % (62^3)
qqqq　は50レス前の絶対バイト位置
現在のファイルポインタよりmm＋１バイトが'\n'なら正常とみなす

【アボーン時の処理】
あぼーん時にdatを詰めるんじゃなくて、同じサイズで塗りつぶすようにする

これでよろしい？

>60
そうですね。　では カンマを２つ入れますか？

でも１０レス程度迄はインデックスは不要じゃないかと思います
10レスまでは インデックス部は無し
50レスまではqqqqはspaceという約束にしては？

>61
bbs.cgiは今でもperlです。read.cgiは元々perlだったのを高速化の
ためCに書き直したそうです。（書き直したのはひろゆきじゃないらしい）

【アボーン時の処理】
＞あぼーん時にdatを詰めるんじゃなくて、同じサイズで塗りつぶすようにする

これなんですが、あぽーんは同時に複数される場合があるので、
　その時された同じスレ内のあぽーんへのリンクを持たせるのはどうでしょう？
　６２進法なら４バイトでよいので収まると思うんですが

キャッシュ分散化とかの話があるなら、あぽーんされた事をキャッシュサーバ側が
高速に検索出来る仕掛けがあった方がいいと思うんですが？

書いた後でなんだけど
キャッシュ分散化が具体的になった後からでも
あぽーん履歴ファイルを別に持たせる方法もあると思うから、あんまり複雑にしない方がいいですね

>65
＞キャッシュ分散化とかの話があるなら、あぽーんされた事をキャッシュサーバ側が
＞高速に検索出来る仕掛けがあった方がいいと思うんですが？
　それを考えているのが、>27で言うところの、「datに削除履歴を残す 」というところなのです。
現在のdatファイルの仕様を逸脱するので、問題ありかなあ、とも思うのですが。
キャッシュサーバは、readdat.cgiで最新レスを取得する際に、あぼーん情報を受け取ることに
なります。で、キャッシュサーバ内のキャッシュされているdatをあぼーんする、と。

>>65
あぼーんも非同期に複数行われるから、いちいちリンクの再構築が必要。
通常の読み書きとの衝突を考えると、datで何でもかんでもやろうとするのは危険かもしれない。

datファイルの書式

【各々レスに埋込案】
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,スレタイトル,nnmmpppqqqq
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,,nnmmpppqqqq

nn は62進数２桁でこの行のレス番号を記録
mm は62進数２桁でこの行のバイト数を記録
ppp 　は10レス前の絶対バイト位置 % (62^3)
qqqq　は50レス前の絶対バイト位置
現在のファイルポインタよりmm＋１バイトが'\n'なら正常とみなす

【アボーン時の処理】
あぼーん時にdatを詰めるんじゃなくて、同じサイズで塗りつぶすようにする

２行目の本文の後ろにカンマ１個追加しました。

datファイルではなくてDBにしよう！

>>70
禿堂

では、
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,,nnmmpppqqqq"n1n2n3n4"
のように、あぽーんがあった時は\nを"に上書きして
削除レス番号を６２進２桁で連ねて記録しておくという方法はどうでしょう？

この情報をそのままキャッシュサーバに渡してやれば、あぽーん情報を
検索するのはだいぶ楽になるのでは？

>>70
mod_zgipを導入するのにもめてる状況でDBが使えるようになるのは、
不可能と思われ。

>>72
そうすると、削除情報を持っているスレを読み込まないと、キャッシュサーバ側が
あぼーんを認識できなくなります。
たとえば５つのレスがあり、既にキャッシュサーバは５までのレスを読み込んでい
るとします。このとき、その内の一つがあぼーんされると、削除情報はレス５の後
ろに付く。その後レスが２つほどついて、次にキャッシュサーバは最新レスを取得
するときは、最新レスとしてレス６−７を読み込む。レス５に保存されている削除
情報がキャッシュサーバに伝わらなくなる。
ということになります。
readdat.cgiなどで、工夫すれば、大丈夫かという気もしますが。

いえこういう感じです
レス１,,nnmmpppqqqq
レス２,,nnmmpppqqqq
レス３,,nnmmpppqqqq
レス４,,nnmmpppqqqq
キャッシュもレス４まで読んでいる


レス１,,nnmmpppqqqq
　　　　　　　　　　　　　 <--レス２があぽーんされた
レス３,,nnmmpppqqqq
レス４,,nnmmpppqqqq"02"

ここでキャッシュは.datのサイズが違うので前回からの差分 02"を読む。
最後が"なので 削除有りと判断　レス２を読み込んでアポーンを確認する

この後に別のレスが続いた場合でも

02"
レス５,,nnmmpppqqqq
レス６,,nnmmpppqqqq

と差分をキャッシュ側が読み込む。　やはり１行目の最終文字が"なのであぽーんに気付く

>>75
>>27の構造をとった場合、アボーンレコードが挿入されるので、
そんな情報は要らないはず

>>77
ただ、その場合キャッシュサーバーが読みにきた時に全ての
レスを再読込しなければならなくなるよ。

>75
実は、datはユーザからは隠してしまった方が良いのではないか？と思ってます。
readdat.cgiを介してdatの最新差分を読むようにすれば、gzip圧縮が効くという話が
前スレ（分岐元）で話していたときあったので。（実はよく分かっていないのですが）
datが見えないからには、ファイルサイズで更新を知ることもできない。
で、削除情報レコードにこだわるわけです。

>78
え、そうはならないはずですが。

キャッシュサーバー用にアボーンファイルを用意するのは駄目？

アボーンされたレスの番号を書き加えていく。
キャッシュサーバーは自分の持ってるアボーンファイルと照合して
異なっている場合のみdatファイルを頭から持っていくってのは？

>>78
例えば

レス１,,nnmmpppqqqq
レス２,,nnmmpppqqqq

キャッシュがレス２まで読んでいるとする

再度キャッシュが読みにきて

レス３,,nnmmpppqqqq
あぼーん２,,nnmmpppqqqq
レス４,,nnmmpppqqqq

キャッシュがレス３から読みこむとあぼーん２レコードから
レス２がアボーンされたことがわかります

>>81
えーっとそれは、
あぼーんした時に、元のレス2を同じ容量で塗りつぶした場合でも？

あぼーん前

<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,スレタイトル,nnmmpppqqqq
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,,nnmmpppqqqq
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,,nnmmpppqqqq

あぼーん後

<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,スレタイトル,nnmmpppqqqq
<b>あぼーん</b>,###########################,,nnmmpppqqqq
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,,nnmmpppqqqq

ってことですよね。
もしキャッシュサーバーがファイルを取りにきた時に
3行目のnnmmpppqqqqの値とファイルの容量の整合性は正常なので
キャッシュを再構築しないって事じゃないんですか？

>78
なるほど。　それも一つのアイデアですね。

ただ、圧縮が有効なのは複数のスレを読み込むためではないのでしょうか？
チャット状態でなければ、キャッシュサーバは殆ど１スレ毎に取り出すような
感じになり、あまり圧縮は効かないのではないかと思います。

また、キャッシュサーバが立ち上がる迄に、かちゅーしゃのようなdat直読型
ブラウザに活躍して貰う場面があると思います。　それらが容易に対応出来る
仕掛けを用意出来ないかなとも思います

すると自前のファイル圧縮（スレ単位に）という事になると思いますが、
やっぱりあぽーんがネックですね。
　一致文字列についてアドレスを記録する方式の前処理が圧縮には有効だ
けど、それを使うと　あぽーんをすると再生出来ない場面が出てくるという

×チャット状態でなければ、キャッシュサーバは殆ど１スレ毎に取り出すような
○チャット状態でなければ、キャッシュサーバは殆ど１レス毎に取り出すような

細分化されるほど圧縮は効きにくいという意味です

>>82
えっと>>81の状態で.dat内容は

レス１,,nnmmpppqqqq
####,,nnmmpppqqqq
レス３,,nnmmpppqqqq
あぼーん２,,nnmmpppqqqq
レス４,,nnmmpppqqqq

となり、キャッシュは前回取得以降を読みこめばアボーン処理ができるという仕組みです
あぼーん２レコードが一つ増えるので、レス無しであぼーんだけでもキャッシュが動作できます

>>85
了解。
途中にあぼーん情報を追加するって事ね。

>>85
　なるほど　その方が条件判断が減るかな・・・でも未対応dat直ブラウザだと
その行そのものがレスとして表示されちゃってレス番号グチャグチャになるかも

それから、インデックスのレス番号はありえない00にしときますか？

レス１,,01mmpppqqqq
####,,02mmpppqqqq
レス３,,03mmpppqqqq
あぼーん２,,00mm
レス４,,04mmpppqqqq
てな感じかな？

datファイルの書式

【各々レスに埋込案】
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,スレタイトル,nnmmpppqqqq
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,nnmmpppqqqq

nn は62進数２桁でこの行のレス番号を記録
mm は62進数２桁でこの行のバイト数を記録
ppp 　は10レス前の絶対バイト位置 % (62^3)
qqqq　は50レス前の絶対バイト位置
現在のファイルポインタよりmm＋１バイトが'\n'なら正常とみなす

【アボーン時の処理】
あぼーん時は同じサイズで塗りつぶすようにする。
インデックスのレス番号に00を入力したレコードを出力する。

あぼーん,,,,,00mm

って感じでどうでしょうか。

>87
＞　なるほど　その方が条件判断が減るかな・・・でも未対応dat直ブラウザだと
＞その行そのものがレスとして表示されちゃってレス番号グチャグチャになるかも
あぼーんレコードを、datファイルのレコードと合わせてやれば、その変更は
そう難しくないだろうと目論んでいます。（ツール作者に期待）

最終的にはreaddat.cgi等で、datを隠蔽して、標準datフォーマットみたいなので
専用UAに返せれば、システムとしてすっきりすると思うのですが、これはCPU負荷
と、圧縮効率との兼ね合いに依りますね。

>88
そんな感じですね。

>>89
L-M　用に秒まで入れます？

>>89 read.cgi に統合される塩梅。
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=998845501&st=823

>90
そもそも「あぼーん」ってのがレアケースだと考えると、そこまで
L-Mの処理をやる必要があるのかな、とも思いますが、まあ、入る
物なら入れて置いて損はないか、と思います。(w
ただ、秒まで含めるか？になると、現在日付フィールドには分単位
でしか日時情報は入っていないわけで、L-Mを計算は、あぼーんされ
たレスと、正常レスとの比較で行うわけですから、秒単位は必要無い
のでは？と思います。もちろん、日付フィールドをtime_tにすると言
うのであれば、話は別です。

このスレの内容には合わないかもしれないんだけど、

キャッシュサーバ間やキャッシュー専用ブラウザ間用に
　独自圧縮ルーチン作ったらどうかと思うんだけどどう？

>83で書いたように　キャッシュは１レス単位にアクセスして
くるだろうから、普通の圧縮は効かないと思う

　　スレの内容って　＞こぴぺ　が多いしょ？
だから、同じ .dat を共有してるって前提で差分転送専用
のルーチンを作れば　相当圧縮出来そうに思う

たとえば日本語に特化した圧縮ルーチンって出来ないかな。
あと、モナー板とかだったら、AAに特化した圧縮ルーチン。
モナーが書き込まれると１バイトに圧縮してくれるようなやつ。

まてよ・・・>>85 の方式だと　複数あぽーんあった時は
レコードも複数用意するの？
>>75 の方法との違いは単に 62進を使うのと \n を使わないだけの差のような気がしてきた

現状のbbs.cgiが仕事してると思われること。

１、datファイルに書込み（新書式決定？）
２、subject.txtに書込み
３、index2.htmlの作成
４、imode用index.htmlの作成
４、スレ用のhtmlの作成

ですよね。
後の作業はどうします？

>>95
だと思いますよ
私は>>27構造が先出で処理も単純だったので>>27を支持しました

圧縮方法ですが、単純な辞書法＋ランレングスだけでいいのではないでしょうか？
つまり、ミラーや.dat直読ブラウザは　nレス迄のデータは持っていて
nレスから最新のレス迄を要求して来ます。
そこで、　互いのファイル上の位置と一致文字数を送ればいいかと

その後ハフマン圧縮をしても、劇的な効果は無い（せいぜい2/3)でしょうし

辞書には「氏ね」「逝ってよし」「オマエモナー」とかいろいろ登録しておけば圧縮効きそうね。

>99　うーん辞書法の辞書は普通同じファイル内の後方参照の事なんだけど・・・

辞書を作るのもアイデアですね

>>99
固定辞書共有による圧縮は、ターゲットのテキストがよほど偏ってないと
かえって効率悪いんではないかと…
静的辞書があったからといって動的辞書を作らなくてもいいというわけでもないし、
インデクスの分だけ固定辞書にとられるのに固定辞書からの参照がほとんど無い
ような特性のデータだとかなり悲惨なことに…

bbs.cgiがindex2.htmの作成をやってるなら　いっそ
index2.htmの作成を1日に1回に制限しちゃったらどう？
これで自然とキャッシュヒット率があがるでしょう

追加：
　　subback.html　も bbs.cgiが作成してるんだったらこれも更新を１日一回程度にしてしまう

多少不便になるけど、read.cgiを使って貰えば圧縮出来るんだからそっちに誘導する方向で考えた方が

とりあえず。背景のレンガ画像を消す。

>102―103
ラウンジみたいに1日に何度もdat落ちする板だと、
すでにdatがないスレを表示し続けるはめになるよ。

>>105　それはそうだけど、index2.htm; も subback.html も現在の状態だと寿命が短すぎる
　　転送量を落とすという目的にはこれの寿命を延ばして自然キャッシュに任せるのが一番
　お手軽かと思ったもんで

・・・なら、いっそindex.htmの内容をアプレットにして
http://piza2.2ch.net/tech/subject.txtから画面作りするのはどう？

>>106
それは index2.html の Last Modified が出てこない &
content-encoding:gzip がうまいこと動いてくれない client
対策をする必要があるという現状を改善するために index2.html
を CGI 化しようということと同義ですね。

>107　そうだね cgi化しちゃえばいいんだよな　read.cgiの分担か

３時間ほど前にこの状況を知り､いろいろ調べているのですが､
全部の過去ログ見れないので、既出だったらすみません。

改良案なのですが､「書き込みのフォームをスレッドにつけない」で、
基本的にROM用というのはどうでしょうか？
最新レス１００ のあとに 書き込み用リンクを貼って
そこにだけ、フォームをつけるのは可能じゃないかと思うのですが？

ROMしてるだけの人って多いと思うし、過去ログにフォームついてるのは？？？
リロードは増えるかもしれないけど…
素人の意見で顰蹙買ったらごめんなさい。

勤務中

　ＨＤＤに余裕が有ればだけど、時間単位か何かで更新情報のみを積めたアーカイブ
を作って判りやすいファイル名で置いておくようにしたら、専用ツールはＣＧＩを介さずに
そちらを参照出来ると思うんだけど……。
　ＣＧＩの負荷って、とりあえずは思考の外？

先日貰った bbs.cgi ありますけど鯖ありますか？

>>109
転送量の低減を狙うならある程度は効くかも。
それにチャット状態の緩和にはいいね。

今も転送量はピーク時60Mオーバーだし、ちょっとの事が効いてくる。

非同期書き込みに対応させるのならトランザクション用のdatを
メモリ中に動的に展開して一定時間ごとにマスターdatに書くのはどう？ダサい？

read.cgiその他のプログラムのIOが変わるけど・・・無理か・・・

>>112
ありますが、アップして大丈夫なんですか？

もう出回ってる奴だし。アップしようか。

>>116
参考になるので、よろしければアップお願いします。

鯖を貸してください。

>>118
使っていいか聞いてきます。

>>118
誰もレスしてくれる人がいないようなので、
ftp://210.170.170.131/incoming/bbs_cgi/
にアップして下さい。

>>107>>108
そのCGIなら、ずいぶん前に
ftp://210.170.170.131/incoming/perler/
にアップロードしたはずです。
index2.c.1というのがそれです。

以下は、批判要望版に書いた物です。バイト数を削減できる話。

基本的にhiddenは使用しない事です。

例えば、index2.htmlの入力フォームの圧縮を図る
現状
<form method=POST action="../test/bbs.cgi">
<input type=hidden name=bbs value=hp>
<input type=hidden name=key value=998275441>
<input type=hidden name=time value=998847349>

このhiddenタグを削除して以下にする。
<base href="../test">しておき、
<form method=POST action="../test/bbs.cgi?bbs=hp&key=998275441&time=998847349">

bbs.cgiでは、環境変数QUERY_STRINGからhidden相当を取り、
　　 標準入力から残りのフォーム変数を取得。現状と互換性あり改造簡単。

将来的には、<form method=POST action="bbs.cgi?hp:998275441:998847349">まで短縮。
変数名なんて明記する必要無し。

まちがえ。
<form method=POST action="../test/bbs.cgi?bbs=hp&key=998275441&time=998847349">
ではなく
<form method=POST action="bbs.cgi?bbs=hp&key=998275441&time=998847349">

>>109

既に意見は出ているのですが・・・。

もう書きはじめた人いる？
誰もいなければ書きはじめるけど(C でいいなら)。

くっきーかなんか使って、一人あたり一日500kbyte以上ダウンロードできなくするとか。

>>112さん
すいませーん。どなたにもらったか教えていただけませんでしょうか？

bbs.cgi は C で書くんですか？

鯖のCPU負荷はあまり問題になっていないようなので，
Perl で書いた方が良さそうな気がするのですが(^^;
その方が早く完成すると思いますし．

% bbs.cgi ってそんなにアクセス無いですよね．たぶん‥‥‥

>>122
それってRFC的に問題ないんでしょうか？
GET/POSTごちゃまぜって標準的にやっていいことなのか
ちょっとわからないので‥‥‥
（現状のブラウザで問題ないという意味ならそれでもいいんですが(^^;）

form method=POST action="../test/bbs.cgi/hp/998275441/998847349">

みたいにして，PATH_INFO 使った方が安全じゃないですか？

ついでに，key/time は 64進数 くらいにして固定長にすれば
更に圧縮可能．（key/timeの間の / も省略出来ますし）

旧形式でのリクエストも受け付けられれば，FORMの形式は
思いっきり書き換えちゃっても大丈夫そうですね．

>>129

HTTP/1.1のRFCに限って言えば、

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

こんな感じでGETもPOSTも区別ないようなんで、大丈夫だと思います。

CGIの方はまだRFC化してないんでしたっけ?
NCSAのドキュメントの方も見てみる必要がありそうです。

>>128
んじゃ、perl にしましょうか。

>>130
うーん、NCSA の CGI specification 見た限りじゃ、POST + QUERY_STRING が
invalid だという明確な記述はないですね。
どうなんでしょ。

>>129
別にPOST、GETごちゃ混ぜって事じゃありません。
METHODと、QUERY_STRINGやPATH_INFOは関係ありません。
ただ、GETの時に情報を渡す一般的な方法がQUERY_STRING
ということでしょう。

＞index2.htm; も subback.html も現在の状態だと寿命が短すぎる
　についてですが

　それぞれ index00.html 〜index23.html のように１時間毎に別ファイルを作るようにして
　 index2.htmlはそれに飛ぶだけにする
　そして１時間ごとにしか更新しない

　というのはどうでしょう？　これでインターネット上のキャッシュが相当効くのではないでしょうか？
　１時間が単位が長すぎるというならこれを１０分単位にするとか

あれ？ index2.html　 の他に index2.htm もあるんですね・・・

もしかして index2.htm が圧縮してる方？

>>131
NCSAの方も見ましたが、問題なさそうですね。
stdinとQUERY_STRINGは併用してOKだと思います。

HTTP/1.1的には、?以降もURIの一部ですので、全く問題ない
はずです。

POST/GETの混在、というのは語弊があるかもですね。
POSTでリクエストする際のURIにqueryを埋め込むという解釈が正しく、
この場合GETは使われません。

すいません、>>131 で perl で書くといいましたが、
手が動きません。C で許して。
じゃなきゃ、perl の達人の方お願い。

unix板から
UNIX 板から既に bbs.cgiでされているらしい対策を拾って来ました

932 名前：ＤｏｌＢａｃｋｙ 投稿日：2001/08/26(日) 00:32
>>886
２時間後に鯖管との相談があるもよう。
動的なデータの圧縮はread.cgiにgzipが組み込まれたのでいけてますが、
最も負荷となるのはやはりindex2.htmlなので、そのへんへの対処としてMOD_GZIPという案がでてます。

888 名前：ＤｏｌＢａｃｋｙ 投稿日：2001/08/26(日) 03:41
とりあえずMOD_GZIPが導入されるまでは、
index2.html：非圧縮
index2.htm：圧縮
・・・として扱おうと思います。
index2.htmlにおいてもリロードなどのリンク先はindex2.htmとなります。


136 名前：ＤｏｌＢａｃｋｙ 投稿日：2001/08/26(日) 04:37
index2.html->index2.htmへの移行開始でーす。

68 名前：ＤｏｌＢａｃｋｙ 投稿日：2001/08/26(日) 05:15
■文字化けにお困りの方へ■
ブラウザのオプションでHTTP1.1の使用をチェックしてください。
※プロキシではHTTP1.1のチェックをはずしてください。
それらの設定が不能もしくは１．１に未対応のブラウザの方は、
index2.htmというアドレスをindex2.htmlに変更してリロードしてください。

これら文字化けの不具合は、MOD_GZIPが導入されると同時に解消されます。
※来週末になる見通しです。

出回ってるソースといえば、これしかないですがね（たぶん
http://mankomankomanko.virtualave.net/bbs.txt
http://mankomankomanko.virtualave.net/config.txt
http://mankomankomanko.virtualave.net/make.txt
http://mankomankomanko.virtualave.net/pageview.txt
http://mankomankomanko.virtualave.net/pass.txt
http://mankomankomanko.virtualave.net/read.txt
http://mankomankomanko.virtualave.net/remake.txt
http://mankomankomanko.virtualave.net/setting.txt

>>136
Perlerさんはお忙しいんでしょうか。。。

>>139
さすがにbbs.cgiをさくさく書くほどの余裕はないです。。

>>272

いちいちもっともです。

が、直す時間がない。。。。

>>273
リロード対策が取れないです。

>141
read.cgi のスレの誤爆ですよね(^^;

>>130-132 >>135


stdinとQUERY_STRINGは併用に関して
私が留守の間に調べてくださったようですみません。
問題ないし、コーディングが簡単なので、私はもっぱらこれを使っています。
逆にpath_info方式は初めて知ったという（＾＾；
独学なのでね（＾＾；

私も時間さえあればコーディングしても良いのですが（＾＾；

>>197

mod_gzipを実装しないとなると、文字化けを解決しないと駄目ですか？

>>138 のスクリプトは、うまく動くものなのでしょうか？
これをいじっていった方が早いかな。
・・・というか、BBS.CGIを作っても使われる可能性はあるのでしょうか？

http://teri.2ch.net/test/read.cgi?bbs=accuse&key=999011907&st=38

これ read.cgi に組み込めませんか？
せめて、
全板のトップにリンクして各板のローカルルールみたいに
「過去ログ検索してね」って。

カテゴリ毎、板毎づつに検索サーバを儲けるとか。
それなら、サーバ提供者も現れそう。

今のところ「bbs.cgiは公開しない」という方針だそうなので、
出来ることは仕様の策定と、実装実験のみですね。

あと、ここまで話し合ってきたdatの新仕様案について、他のス
レッド（ミラー、Ｐ２Ｐとか）の方々とか、実際動いているスク
リプトの保守をしている管理側の方とか、monazillaプロジェク
ト（専用UAの作者）の方々とかの意見が聞きたいです。
特に現在のbbs.cgiの保守をされている方の意見が聞きたいなあ。
（このスレッドは見られているのでしょうか？）

簡単に現在出ている案をまとめます。（括弧内は私見です）

◎あぼーんを塗りつぶしで行う
　ほぼ同意を得られたと思っています。特に反対意見は無かった。

◎インデックスの作成方法。
・別ファイル（一番単純だけど、別ファイルになるのが何とも）
・dat冒頭に２０レス毎、５０レス毎の領域を作る。（単純さは
　良いのだが、現在のdatの仕様とかけ離れてしまいそうな。）
・dat冒頭に１０００レス分領域を作る（１０００全部は要らないような）
・レス毎にフィールドを作成し、１レス前５０レス前等のインデ
　ックス情報を追加。（現行のdatに即するならベスト。ただ、
　作成、解析の手間が煩雑かな。）
（どれにせよ、インデックスの修復機能は実装する必要がある）

◎あぼーん情報
・datのレコードに即した構成であぼーんレコードをdat内に追加する。
・レスの毎にフィールドを追加して、あぼーん情報をそこに納める。
（あぼーん情報の保存方法は、どっちもどっちの様な気がしてます。）

>144
>138のソースは、昔の2chの物だそうです。キャップのパスから間違い
ないという話がありました。実装実験には使えるのでは無いかと思い
ます。
＞・・・というか、BBS.CGIを作っても使われる可能性はあるのでしょ
＞うか？
何とも言えませんが、今は出来ることをやるしか……。みんなひろゆきの
公式発表を待っている様な気がしますが、それでは遅い、と思ってます。

とか言いながら、本業がマジでピーンチ！の状態なので、今日は何も
できない……。

>>146
質問なんですが、あぼーんは巨大AAコピペの削除とかにも使われますよね？
そういったものを削除した場合、read.cgiや2ch専用Browserの方であぼーん情報をdatから
取得して、塗りつぶした部分を改行一つに置き換えるといった操作をするようにするんでしょうか？

>147
専用UAがあぼーん情報をどの様に扱うかは、専用UAの実装に任せた方が
良いと思います。
あくまでも「塗りつぶし」ってのはインデックス情報をなるべく書き換えたくない、
という理由です。インデックスはread.cgi/readdat.cgiの負荷を減らすのが主理
由ですので、専用UAがインデックスを利用するか、しないかは専用UAの実装
に任せた方が良いと思います。

以下独り言。
たとえば、既にあぼーんされているレスを読み出す時は、塗りつぶしたレスを
返すのではなく、read.cgiで「あぼーん」と短く書き換えて渡す方が良いかもし
れない。でも、その場合、インデックス情報の意味が無くなるから、インデック
ス情報はユーザからは隠すべきかなあ。

>>148
なるほどです。。。

＞あぼーんは巨大AAコピペの削除とかにも使われますよね？

そうか、あぼーんのときに本文を全部 ####### とかで埋め尽くす方法だと、
「スレッド大きすぎます」が解決しないのか

>150
「このスレッド大きすぎます」のエラーは、read.cgiの負荷を減らすのが
目的ではないかと。現行のread.cgiは一つのレスを返す場合でも、datを
全部読んでから吐き出す仕様になっているため。インデックスを導入す
れば、このエラーは無くしても良いのではないのかな、と思ってます。
HDDの容量の事は考えてません。(w

read.cgi では、「あぼーん」1行で済ますとしても、
でも専用UAでは dat 読むんだから、ファイルの容量が大きいままだと
通信量がかさむなぁ・・・と思ったのです。

会社からの帰りに考えてたのだけれど、
専用UAは read.cgi からレス範囲指定で読み込むように
してもらうんでしたっけ？それなら平気、かな・・・？

>153
＞専用UAは read.cgi からレス範囲指定で読み込むように
＞してもらうんでしたっけ？それなら平気、かな・・・？
それが理想型だと思っているのですが、反発必至かなあ。
特に専用UA作成者から。(w
あとreaddat.cgiの負荷の問題もありますし。理想型は、インタフェースは
全部cgiにして、datはユーザから隠すことだと思います。

P2Pcache すれから出張です (^^;;;

こちらから.dat ファイルの形式に関する要望としては

・datにハッシュ(MD5)を一緒に埋め込んで欲しい
・インデックスを修復してもあぼーんしたメッセージを飛ばさないでほしい
（レスのIDが変化しないようにして欲しい）
・レスのIDはスレ内で一意で且つ順序比較が可能であること

です。ではでは。

datの形式はどうするのでしょう？

１．従来の専用UAと互換性を保つ形にとどめる．
２．従来の互換性を考えず新しくする．

１か２が決まらないでフォーマットの話をしても収集しそうに
ないので，それをまず決めるか，それぞれを想定して
フォーマットを想定した方が良いのではないでしょうか？

２ｃｈは現在転送量の削減が最優先ですから，２の場合，
日付フィールドやIDなどはバイナリで埋め込むことも検討
してみてはどうでしょう．
（ID は１文字6bitで表せそうなので，８文字->６バイトに圧縮可能かと）

% あぼーんは，日付フィールドが 0x00000000 ということにするとか．

フィールド区切りも <> というのは無駄ですし‥‥‥．
日付やIDは固定長なので，区切りを入れる必要もないです．

例えば，以下のような形式．

日付4byte，ID6byte，名前長(1byte)，名前，メアド長(1byte)，メアド，本文長(2byte)，本文

<br> はやめて，\n １文字にする．
>>xxx 形式は，0x01 + 2byte 記事ID，とかにすれば，
これもサイズ低減に役立ちます．

gzipのためread.cgi経由ぬするとしても，やはりバイナリで出力する方が
通信量の削減には繋がると思います．

% index は，サーバー側CGIだけが読めればよいので，
% datの中に入れるのは通信量を増やしてしまいよくないかと‥‥‥．

個人的には，転送量最重要ということを考えて２の方向が
良いんじゃないかなぁとは思いますが‥‥‥．
（専用UA作者から反対が来るとしても，２ｃｈ自体が無くなってしまっては
　意味がないので(^^;）

現在の転送量
まだまだリミットの５Ｍを越えているよ。

http://news.kakiko.com/mentai/20010829/

datファイルに関して言えば、生データは外部に出さず、read.cgiから
吐く方針で良いですよね？

すると、ＵＡ向け、ｐ２ｐｃａｓｈ向けのフォーマットは、それぞれ
read.cgiで吐く事にして。。。。。
生datのフォームを決めてしまいたいですね。
あと、運営関係者の意見を聞きたいです。

瞬間最大5M越えるとヤバイのか？
であれば、転送量軽減してもだめじゃん
（＝利用者の数制限しないと軽い分だけ転送回数が増えて同じこと）

>>156
一生懸命 bbs.cgi を書き直していて思ったのですが、
現在の dat の形式はあまり扱いやすくない(たとえば
レスがいくつあるか、dat からはすぐにはわからない)
ので、あたらしい dat 形式を考える方がいいと思いま
す。できれば、ファイルの先頭に現在のレス数をつけ
たいですね。

　えと、素人考えなのですが。
　発言ごとに圧縮した物をマージして置いておけば、圧縮データをＣＧＩを介さずに
差分読み出来ると思うのですが、１発言単位だと圧縮率落ちますか？(^_^;)

>>161
落ちるも何もかえって増える。

>>161
増えるってのは圧縮後の容量が元より大きいって意味ね。

>>161 餅論。
HTTPで使われる圧縮は、基本的に相関圧縮
(以前にあったストリームと似たものを使う)なので、
単位圧縮はあまり効率的ではない。

そもそも、圧縮したストリーム同士を簡単に
合成できると思ってるのかね?
(答えを知ってる人は黙っててne!)

>>161-162

ダメだと思いましたが一応実験してみたので．
part が１記事ずつのもの．

gzip ならわずかながら小さくなる程度ですね．

[mikage@mahoro tmp]$ ls -l 985966661.dat* | perl -pe 's/mikage/Sherry/g;'
-rw-rw-r-- 1 Sherry Sherry 219671 Aug 12 01:33 985966661.dat
-rw-rw-r-- 1 Sherry Sherry 52842 Aug 30 01:49 985966661.dat.bz2
-rw-rw-r-- 1 Sherry Sherry 68793 Aug 30 01:49 985966661.dat.gz
-rw-rw-r-- 1 Sherry Sherry 236824 Aug 30 01:51 985966661.dat.part.bz2
-rw-rw-r-- 1 Sherry Sherry 204974 Aug 30 01:52 985966661.dat.part.gz

>>165

アカウント名消そうとしたのに思いっきり晒してるし．．．(汗)

逝ってきます．．．

>>162-165
　ずぇんずぇん駄目ですね。失礼しました……。m(__)m

　えと、素人考え第２段。今度は自力検証しました。(^_^;)
　固定辞書で圧縮、みたいな話がどこかに書いてあって、その時は否定的な
見解が多かったんですが、もっと単純に全角ひらがなを半角カタカナに変換
して半角カタカナをエスケープしちゃうのは？
　手持ちのテキストでいくつかやってみたんですが、圧縮後でも多少は効果
がありました。５％程度かな？

>>168

問答無用で，英数字カタカナを全部半角にしてみました．
こうするとかなり減りますね．
（でも苦情出るかな‥‥‥さすがに．(^^;）

z2hがついているのが半角変換を施したものです．

$ ls -l 985966661.dat*
219671 Aug 12 01:33 985966661.dat
52842 Aug 30 01:49 985966661.dat.bz2
68793 Aug 30 01:49 985966661.dat.gz
209871 Aug 30 02:34 985966661.dat.z2h
52616 Aug 30 02:35 985966661.dat.z2h.bz2
66865 Aug 30 02:35 985966661.dat.z2h.gz

英数字はそんなに害が無い感じですが，半角カタカナは
結構読みにくい．．．

>>169
　あ、さすがにＨＴＭＬ出力でそれはイヤです。(^_^;)
　専用ブラウザ用に独自仕様のｄａｔファイルをＣＧＩ出力するなら、その時だけ
でも固定辞書変換を掛けたらいいんじゃないかな、と思いまして。

えっと、dat の先頭 18 byte をヘッダとして確保してはじめの
2byte がレスの数、16byte が md5、残りは Sherryさんの言うよ
うにバイナリ形式、というのはどうでしょう？
(MD5 って 16byte ですよね？)

>>171
MD5って何の目的で使用するんでしょうか？
datファイル自体の整合性のチェックには向かないと思うのですが‥‥‥
（DATファイルをクライアントが読み込んでいる間にファイルが書き変わる
　可能性があるため）


ヘッダ：
2bytes: レスの数（あぼーん記事は含むが，あぼーん情報分は含まない）

記事：
日付4byte，ID6byte，名前長(1byte)，名前，メアド長(1byte)，メアド，本文長(2byte)，本文

<br> はやめて，\n １文字にする．
>>xxx 形式は，0x01 + 2byte 記事ID，に変換
>>xxx-xxx 形式は，0x02 + 2bytes + 2bytes に変換．
（, 区切りは上の２つの形式に分解）

記事があぼーんされた場合は，

あぼーん記事：
日付，ID，名前，メアド，本文を 0x00 で潰す

更に，あぼーん情報を

あぼーん情報：
0xffffffff, 2bytes 記事番号

でファイル末尾に追加する．
（日付が0xffffffffの場合は記事と見なさない）


というのでどうでしょう？
差分読み込みしたとき，あぼーん情報を追記分から読み取り，
クライアント側で記事の塗りつぶしを行えば，ファイル全体の
再転送も防げるかと思います
（P2P向け．普通のUAで見るなら，わざわざ過去分をあぼーん
　する必要も無いと思うので‥‥‥）

>>168-170
別スレで固定辞書に異論を唱えた一人だけど、元テキストの特性に依存
するのはやっぱりマズイ。
AAがかなりの割合を占める場合なんか特に。

>>166
俺は薄々気付いてたよ（ｗ
つかHUCOM以来か。なつかしくもあり…

>>173
ぁぅ（＾＾；
といってもそのころのことはもうほとんど覚えてなかったり(汗)

>>172

いくつか補足．

・スレタイトルは，最初の記事の本文の１行目（\nがでてくるまで）にする．

・上では，本文中で 0x01，0x02 を使っていますが，0x00, 0x03-0x09,
　0x0b-0x1f, 0xff あたりも何らかの用途に使えると思います．
　例えば，
　0x10 + 2byte 記事番号 + 開始オフセット(1byte) + 取得長(1byte)
　0x11 + 2byte 記事番号 + 開始オフセット(2byte) + 取得長(2byte)
　のようにして，以前の記事の内容を持ってこれるとか．
　同じＡＡが連続してたり，他の人の記事の引用の場合に
　元で圧縮できるのでそれなりに効果はあるかと‥‥‥．
　（書き込み処理が重くなりますが‥‥‥）

・過去ログに移すときは，あぼーん情報は取り除く．
　（一括でしか読み込まないなら意味はない(^^l）

>>173
　変換を掛けたか掛けていないかのフラグを付ければ、ややこしく
はなるけどデメリットはほぼ無くせませんかねぇ。

かなり無茶な圧縮ネタです。

１）投稿文中の全ての半角文字を全角文字に変換
２）１文字16ビットの全角文字を、前半8ビットと後半8ビットに分離
３）前半8ビットだけを集めた文章データを作る
４）後半8ビットだけを集めた文章データを作る
５）３と４を結合
６）５を圧縮

ただ言ってみたかっただけ（＾＾；
忙しいところ邪魔してスミマセン。

　あと、各板のデフォルトの「名無しさん」を別データで持つようにして、
それと同じ「名無しさん」はｄａｔ上は空白にしてしまうとか……。

こんなの見つけた。

ftp://210.170.170.118/incoming/old_bbscgi/

>>88　から　datファイルに埋込案のまとめ

【各々レスに埋込案】
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,スレタイトル,01mm
<b>名前</b>,sage,01/04/06 22:50 IDxxxxxxx,本文,nnmmpppqqqq

nn は62進数２桁でこの行のレス番号を記録
mm は62進数２桁でこの行のバイト数を記録
ppp 　は10レス前の絶対バイト位置 % (62^3) １０レス迄は空白
qqqq　は50レス前の絶対バイト位置 　50レス迄は空白

【アボーン時の処理】
あぼーん時は同じサイズで塗りつぶすようにする。
インデックスのレス番号に00を入力したレコードを出力する。

あぼーん,,,,,00mm

read.cgiは、ファイルサイズを取得した後、
現在のファイルポインタ(サイズ)-(mm＋１)バイトが'\n'なら インデクス有りとして
10レス前は、ファイルポインタ=adr として adr - (62^3) + ( ppp + (62^4) - adr) % (62^3)　で取得
50レス前は、qqqqから取得
レス番号指定の場合は、nnから何レス前か割り出せば最悪 qqqqを19回 pppを4回mmで４回遡ればよい

read.cgi や bbs.cgiが datを読むとき、最終行の nnは信用しない事
pppを使って１０レス前のレス番号から割り振りなおす事

62進数でなく英字だけの52進数にしても
２桁　　 2704
３桁　 140608
４桁　7311616
と十分表現出来るので　英字だけにした方があきらかに１０進法と
違うと判るという意味で良いかもしれません。

/*５２進数から元に戻す*/
int　from52(const　char　*s,int　cnt)
{int　i;
int　ret=0;
　for(i=0;i<cnt;i++){
　unsigned　c　=　*s++　　-'A';
　　if(c>('z'-'A'))　return　-1;
　　if(　　('z'-'a')　<　(c&0x1f)　)　return　-1;
　　if(c>=('a'-'A'))c-=　('a'-'Z'-1);
　　ret　=　ret*52+c　;
　　}
　return　ret;
}
/*５２進数文字列を作る*/
void　to52(int　dt,char　*d,int　cnt)
{int　i;
int　ret=0;
　for(i=0;i<cnt;i++){
　　int　c=dt　%　52;dt/=52;
　　if(c>=26)　c+=('a'-'Z'-1);
　　c+='A';
　　d[cnt-i-1]=c;
　　}
　return　ret;
}

10レス前の取得だけど
移動窓方式だろうけど-1が 入ってないと まずい

/* pppが正常でなければ -1を返す */
int pppToPtr(int nowp,const char *ppp)
{ int r=from52(ppp,3);
　if(r<0) return -1;
　return nowp-(52*52*52-1)+(r+52*52*52*52-1-nowp) % (52*52*52);
}

やっと怒濤の一週間が終わった……。

>156
あまりに急激な改変は如何な物かと。最終的にどの様なフォーマットになるにしろ、
現在のシステムがあるからには、その過渡期ってのがあるわけで、そこら辺をどの
様に処理していくかも問題になると思います。
１から2chタイプのBBSを作るのであれば、そのようなフォーマットも*あり*だと思い
ます。

圧縮ですが、これってread.cgiへの負荷はどのくらいになるのかなあ。実験してみな
いと分からないですね。あと、全角を半角にするのは……ＡＡがずれる……。

６２進数ってのは、なんであと二文字足して、６４進数にしないのですか？その方が
計算が遙かに楽になると思うのですが？

なんか、いちゃもん付けばっかりになってすいません。つか、この１週間ほど、家に
帰ってないので、今日は帰って寝ます。（家にはネット環境はありません。）

ひろゆきの発表は今夜なのかなあ。一応存続は決まったような雰囲気だけど、
我々のやっていることは、果たして意味があるのだろうか？

>>182
最後の一文に激しく同意。
意味がないから無駄、とは思いませんが。。。

逆だと思う。
無駄だから意味がないとはいえない。
2chにとっては無駄になっても、
2ch 型掲示板の新しいアーキテクチャの模索が全く無意味だとは思わない。

>>184
2chにとっては意味がなくても、
2ch型掲示板の新しいアーキテクチャの模索ができているから無駄だとは思わない。

。。。おそらく、異口同音かと（＾＾

2chは今後どうなっていくのでしょう。。。

>183-185
あい、同意します……。

>185
そうかも。

正直、ここで動いているような人たちが管理側に入らないと
システム面の革新はないと思うね。

>>182
>６２進数ってのは、なんであと二文字足して、６４進数にしないのですかその方が
>計算が遙かに楽になると思うのですが？

前スレからの流れだと思います。

６４進数にするとすれば
http://www.kurume-it.ac.jp/home/general/sibhome/moji/encode.html
のどれかと思いますが、　BASE64方式が一番無難かとは思います
英字＋数字　と後　＋／の２文字を足す事になります
前のスレでは、スレ番を６４進数にすると/が入るのが問題かもという話だったのでは？

ただ、今回はファイル中の文字なので、+/の両方とも特に問題になる文字じゃないよう
に思います

６４進数が遥かに楽になるにはこの変換関数がperに標準で 備わっている場合
だけだと思いますが、どうなんでしょ？
まあテーブル引き方式にすれば　６２　５２　６４どれでも同じだと思います
if文で作るなら　uuencode 次に 52進数が一番軽いですが
uuencode は , (カンマ）を含んでいるので使えないでしょう

ただ６４にすれば、 /% が シフトと & で代用出来るメリットがあると思います

何でも良いと言っても、決めないと進めないので決めてしまいませんか？

>>188
じゃあ、A-Za-z0-9+/ の 64 文字を使いましょう。
で、dat のフォーマットがテキスト、ということなら、
最初の一行にレスの数とスレのタイトルを入れて、
残りは一行一レスというのでどうでしょう。

dat ファイルに関する IO 部分だけ perl で書いておいて
bbs.cgi が最小限の変更で済むようにすれば取り込んで
もらいやすいんじゃないでしょうか。

read.cgiより出張してきました♪

明日(ってか今日)、indexを実装して
みようと思うんだけど、最低限の
ファイルフォーマットを決めさせてもらいます。

+0000 unsigned long version;
1から始めます。

いじょ。

>191
ファイルの先頭や途中を書き換える方法は簡単そうだけど、
複数のプロセスで書換えられる事を考えると、ロック・アンロックが失敗した
時に酷い目にあうように思います。
普段は出来るだけ追加だけですむ方法が安全ではないでしょうか？

>>193
書き換えを一方向（0→1しか書き換えない）のであれば多少安全では。
dat ファイルの先頭に 1000 byte 領域確保して
それをあぼーんフラグとして利用するというのはどうでしょうか。
ついでに 4000 byte 確保して記事位置 index を作ってもよいかも。

あぽーんの時なら、読み込みもロックして完全に他のプロセスが読み書き出来ない状態で
書き換えてもそれほど頻度が多くないので問題ないと思います

しかし、たとえば、ファイルの先頭にレスの数を書く場合、読み込みについてもロックしなければ、
他のプロセスが１０レスがあって２つのプロセスが同時に１０を読んでから１１を書いてしまうと
本来１２になるべきレス数が１１と少なくなってしまいます。

たまに時間の分の単位が逆転する現象をみかけます。
これは、先に起動したプロセスが必ずしも先に書き込める訳ではない事を意味してると思います
から十分にありえる事ではないでしょうか？

しかしROMが書込みの１０倍はあると思いますから、読み込みまでロックをするのはどうかと
思います。

後ろに追加書込みする方法 >>179 は、一瞬自分のレス番号については間違う場合はありえるけど
プロセスが書いた後、再度１０レス前から読み込みしなおす事で自分の間違いに気付ける＝
書き直せば良いのでよいと思います

ファイルの先頭にレス数を書きたい理由は、新たなレスを
書き込むときのチェックが速くなるからです。
最初の１行を読んでしまえば、1000 に達しているかどうか、
すぐに分かります。また、1000 未満だったらファイルの
最後に seek するだけで書き込みができます(このとき、
"r+" で開いてロックをかけてしまいます)。
さもないと、dat ファイルを全部読み込んで、レス数を
カウントしないと、レス番号が分かりません(しかもその
間ずっとファイルを lock しておかなければなりません)。
ちょっと perl でレス追加の部分を書いてみました。
全部読んでカウントするよりいいとおもいますが。


my $fh = new FileHandle $datfile, "r+";
unless (defined($fh)) { ... }
unless (flock($fh, LOCK_EX)) { ... }

my $header = $fh->getline;
chomp($header);
my $res_num = substr($header, 0, 2);

if ($res_num >= 1000) { ... }

++$res_num;

$fh->seek(0, SEEK_SET);
$fh->print 新しいレス番号かきこみ;

$fh->seek(0, SEEK_END);
$fh->print レスを一行で;

$fh->close;

>>195
bbs.cgi は常に flock を掛ける、という方針でいいんじゃな
でしょうか。
read.cgi は flock を掛けなければ、bbs.cgi が書き込み中
だろうと読み出せるわけですし、レス番があってるかどうか
を気にするのなら、先頭のレス番号情報は無視して、各行を
読んでいけばいいだけでしょう。

いや後ろに追加書込みする >>179 でも
ファイルサイズの後数バイトを読み込めば　レス数が判るのでは？

確かに、 bbs.cgiで　flockしてから読んで書けば大丈夫だと思います

時間がたまに逆転する事から、今のCGIは書込みの直前でロックしてるのではないかと思います

まあ先頭にレス番号があれば全部を読み込む必要が無くなるから、高速になるので
それくらいのロック時間は何でもないかもしれませんけど・・・・

でも後ろにレス番号を書いておく方法でも同じ効果がえられるのと、
read.cgiとかからの検索効率も上がるのでそっちがいいんじゃないかと

2ch for sale? ;(

むむ、売りに出してしまいましたか。どうなるんでしょう。

とりあえず、末尾の index を見るなら、こんな感じでしょうか。
{ ... } はエラー処理して、抜けてしまうということで。

my $fh = new FileHandle $datfile, "r+";
unless (defined($fh)) { ... }
unless (flock($fh, LOCK_EX)) { ... }

$fh->seek(-12, SEEK_END);
my $tail = $fh->getline;
unless ((split(//, $tail))[-1] != '\n') { ... } # 末尾が '\n' じゃない

my $res_num = substr($tail, 0, 2);

if ($res_num >= 1000) { ... } # 本来のレス番より小さくなることはない

my $new_res_num = &check_prev10($fh, $tail); # 10 前からチェック
if ($new_res_num >= 1000) { ... }

$fh->seek(0, SEEK_END);
$fh->print レスを一行で;

$fh->close;

スレッド情報／レス情報は別ファイルにしたいものですね。
datの先頭に書くと、タイムスタンプ変わるしファイルサイズも変わる。
998921988.datに対応した998921988.idxを作る方法だったら、ファイルチェック手数も少なくて済むです。
そもそも、dat全部読み込んでから頭なんバイトをチェックするのは不効率だと思うです。

http://www.writing-space.com/

トップページについては一杯食わされた模様（藁

まさかとは思うけど、件の夜勤★さんの発言からして、
このネタのための前フリだったんじゃあ、無いだろうな。
西スレで厨房ぽく「助けて」とか言ってみたり、妙に★付きが
色んなところで思わせぶりな発言をしたり。

なんだよー。
この板のログ資源まで全部売り物になっちゃったのかと思って
半べそだったのに・・・ネタだったのか・・・ｶﾞｯｸｼ :-p

「名前：」「投稿日：」
はやく消せや

age

外出だと思うけど、
現在のbbs.cgiが公開できないのであれば、
管理側に「ここをこうしてください」ってお願いするのは駄目なの？

コードを指定するんじゃなくて、
「板のTOPページの下（最新レス一覧）を出さないようにして」とか。

外出だけど、いまだにそれが出ているから気になって。
あれがなければけっこう負荷が減る気がするんだけど…。

mod_gzipやread.cgiの改良で目標の転送量1/3が達成できず、しょうがないから bbs.cgi も
ソース公開っていう流れを密かに期待しているのは私だけ？

>>209

ftp://210.170.170.118/incoming/old_bbscgi/

外出かもしれませんが、
ROMが圧倒的に多いのならレス入力部分を別にすればよいのではないでしょうか?
現スレッド作成みたいに。

>>209 bbs.cgiは、セキュリティ上の問題があって公開に踏み切れないと
聞きました。（キャップの情報や、その他改変の危険など）
ですから、こちらで書き換えたものをそのまま使ってくれって渡しても
おそらくまるまま差し替えはできないのではないかと…。
ですから、スクリプトを指定するのではなく、「これが出ないように…」とか、
言葉で指定するしかないんじゃないかな…と思ったんです。

>>210　それって、確か娘。さんが「むかーしの」と言っていたやつですよね？
一応それを基準に改良を加えてたと思いますが…。

>>212
後段＞ええ、そうです。
前半＞同意です。

>>211
それ、どっかでけっこう出てましたね。
＃６４１１さんあたりが、２chの勢いがなくなるかも…って言ってた気が…。

>>213
レスありがとうございます。

その辺の意思伝達は、どうなってるのでしょうか。
今現在は、夜勤さん★あたりの人がこのスレを読んでくれないと
どうしようもない感じなんでしょうか。
夜勤さんも、自由にできるのはresd.cgiだけだって言ってたし…。

http://cocoa.2ch.net/test/read.cgi?bbs=unix&key=998695422
で、夜勤さんメルアド用意するって言ってて、そのままになってますよね…。

Perlerさんはメルアドどっかで公開してましたよね。ホットメールの。
夜勤さんから連絡行ってたりしないのかなぁ。

/* 値部分の開始位置と長さ */
value_start = tgt_len + 1;
value_len = line_len - value_start;
/* 長さを丸める */
if ( value_len > MAX_GETSTRING_VALUE_LEN )
value_len = MAX_GETSTRING_VALUE_LEN;
/* 値をコピー */
memcpy( dst, line + value_start, value_len );
dst[value_len] = '\0';
return dst;

↑のを（[[zz_GetString()]]）
↓のようにしたら速くなるでしょうか？

/* 値部分の開始位置と長さ */
value_start = tgt_len + 1;
/* 長さを丸める */
if ( line_len > MAX_GETSTRING_VALUE_LEN+value_start )
{
memcpy( dst, line + value_start, MAX_GETSTRING_VALUE_LEN );
dst[MAX_GETSTRING_VALUE_LEN] = '\0';

}
else
{
memcpy( dst, line + value_start, line_len - value_start );
dst[line_len - value_start] = '\0';
}
return dst;


もしクソだったらすいません。

>>214
bbs.cgiの改造に関していえば、かなり単純明快に「××を削れば必ず○○byteの
得をする」という提案でないと、今は作業していただけないような感じがします。
他に優先すべき検討課題がいろいろあるのでしょう。
その意味で、実装に手間がかかったり、効果が確実でなかったりするものは、
（とりあえず今は案を温めて）後回しにした方がよいかも。

なるほど…。

read.cgiのほう、けっこう実装も進んでいるようで、喜ばしい限りです。
名無し娘。さんがいなければ、ここまで来なかったでしょうね。
本当にお疲れさまです。
法人化に伴いサーバーが確保できたら、mirrorのコードも活用できるといいですね。

sage忘れました…。
ｽﾏｿ。。。

bbs.cgiのパス仕様対応を希望します。見栄えにまったく影響を
与えることなく、
・index.htmlを約0.9KB
・subback.htmlを約7.8〜10KB
・/i/index.htmlを約1.2KB
の節約効果が見込めます。

具体的な変更点とその節約効果を説明します。
[index.html]
・スレッドメニューのリンク
../test/read.cgi?bbs=板名&key=キー&ls=50
↓
../test/read.cgi/板名/キー/l50
で、10 * BBS_MAX_MENU_THREADバイト節約

各スレッド最後の
・レスを全部読む
../test/read.cgi?bbs=板名&key=キー
↓
../test/read.cgi/板名/キー/
・最新レス50
../test/read.cgi?bbs=板名&key=キー&ls=50
↓
../test/read.cgi/板名/キー/l50
・レス1-100
../test/read.cgi?bbs=板名&key=キー&to=100
↓
../test/read.cgi/板名/キー/-100
で、BBS_THREAD_NUMBER * (7 + 10 + 10)バイト節約

現在の標準の
BBS_MAX_MENU_THREAD=30
BBS_THREAD_NUMBER=10
を当てはめて計算すると、570バイトの節約になります。

[subback.html]
<base href="http://サーバー名/test/" target="body">
↓
<base href="../test/read.cgi/板名/" target="body">

<a href="read.cgi?bbs=板名&key=キー&ls=50">
↓
<a href="キー/l50">

<a href="../板名/kako/"><b>過去ログ倉庫はこちら</b></a>
↓
<a href="../../../板名/kako/"><b>過去ログ倉庫はこちら</b></a>

で、(20 + 板名のバイト数) * スレッド数 バイト節約できます。
批判要望を例に取ると、300スレッドで約7800バイト、
400スレッドで約10400バイトになります。

[i/index.html]
BASE要素を追加
<base href="../../test/read.cgi/板名/">

<a href="../../test/read.cgi?bbs=板名&key=キー&imode=true">
↓
<a href="キー/i">

<a href="../../test/pageview.cgi?bbs=板名&page=2&imode=true">Next Page.</a>
↓
<a href="../../pageview.cgi?bbs=板名&page=2&imode=true">Next Page.</a>

で、(38 + 板名のバイト数) * 30 - (35 + 板名のバイト数) + 5 バイト節約
批判要望なら1284バイトです。

レスリンクに関しての説明を忘れてた。
・範囲指定の場合
../test/read.cgi?bbs=板名&key=キー&st=○&to=△
↓
../test/read.cgi/板名/キー/○-△
で、1個につき14バイト節約

・1レスだけ指定の場合
../test/read.cgi?bbs=板名&key=キー&st=○&to=○&nofirst=true
↓
../test/read.cgi/板名/キー/○
で、1個につき29〜32バイト節約

できればレスリンクはdat生成時ではなくdatをhtmlへ
整形するときに付けてほしいです(URLのリンクと同じ扱い)。

BASEって絶対URIでないとだめなのね。考えてみたら当たり前か。
pageview.cgiを復活させるつもりがないならi-mode用
のNext Page.は丸ごと取り去ったほうがいいかも。

read.cgi/板名/ までが見かけ上ディレクトリになるので、
BASEに含めることが可能になるのがミソ。

最新５０が、反映に時間かかるね〜
<a href="キー/l50">　と　<a href="read.cgi?bbs=板名&key=キー&ls=50">の　時間差ってことかな
　

反映に時間が掛かるのは実況対策だから正しい
つーかスレ違いでは?

>>210のスクリプトは２ｃｈで使われている物ではない。このスレで１７氏が開発している２ｃｈクローンのスクリプト。
それから、１７氏は本家にフィードバックする気はないらしいのでその辺は考えといてね
http://corn.2ch.net/test/read.cgi?bbs=php&key=998794497

>>228
それは2chのものが流出したと言われていて
17氏がもとにしたスクリプトだよ。

age