bbs.cgi再開発プロジェクト5

>951
ひろゆき氏になんとか説得してみますよ。

<dat>
  <res name="動け動けウゴウゴ２ちゃんねる" mail="sage" date="2005/04/08(金) 17:46:04 ID:AQwRoo140">
    その論理はちょっとおかしい気が &lt;br&gt; xmldb(?)で〜 &lt;br&gt; ならまだわかるけど
  </res>
  
<res name="動け動けウゴウゴ２ちゃんねる" mail="sage" date="2005/04/08(金) 17:51:04 ID:+8zeIhpi0">
    高度なネタですね
  </res>

</dat>

>>952
がんばれ

>953そんなかんじで
修正を加えると
<log>
<res num="948" name="動け動けウゴウゴ２ちゃんねる" mail="sage" date="2005/04/08(金)" time="17:46:04" ID="AQwRoo140">
その論理はちょっとおかしい気が <br> xmldb(?)で〜 <br> ならまだわかるけど
</res>

<res num="949" name="動け動けウゴウゴ２ちゃんねる" mail="sage" date="2005/04/08(金)" time="17:51:04" ID="+8zeIhpi0">
高度なネタですね
</res>

</dat>
相談：このような場合、レスアンカーはどのようにすれば 指定したレスに飛ぶんでしょうかね？/スレ番.xml?num="レスNo."でOKでしょうか？
>954あり
言い忘れたけど、HTML化も不要だな。
HTML同然だし。

ｽﾏｿ修正
</dat>→</log>

XMLは、いろいろなところで流行りだったりして、
各種フォーマットをそれにするというのは、センスとしてはむろんありえます。

で、もし２ちゃんねるのようなものを一から作るとしたら、
XMLベースでいくというのはかなりありえますが、
既に動いている２ちゃんねるに導入するからには、
「作るに足る大きなメリット」言い換えれば「XML化によって見える果実」が
必要な気がします。

後ろにDBを置きやすいとか、標準形式だからブラウザ作ったりする人が対応しやすいとか、
将来の拡張が容易とか、そのへんのもの＊以外＊に、何かあるといいかもです。

より、実利的な何かがいいかも。
例えば、10倍負荷に強くなるとか、かける工数に対してメリットが目に見える形で存在するなら、
その気にさせる動機になるかもです。

ここの掲示板は「非互換な形にいきなり内部形式を変える」ことには、かなり軽く動くところがあるので、
果実が甘くておいしいなら「いきなりバサっと導入」は、常にありえるかと。

大幅な仕様変更で専ブラ使えなくなったら困るぞ

メリット無くてもデメリットさえあってもひろゆきがやるといったらやる悪寒

html同然ってことは●の販売数落ちるかな？

常に全レス読み込みか、

そうか、Ajaxか…。だがしかし、、、

>>961
転送量を考えれば XML にしたって
read.cgi かなんかでの行数制限読み込みは必要だろう

２ちゃんの負荷分散は専ブラによるところが多い。
現在はIEや携帯の負荷を分散させる作戦中。
１００％htmlベースの通常の掲示板というのはシステムの増強なしには無理でしょう。
有料化など収益があれば別ですけど。

「bbs.cgiスレでXML化を言い出す奴=Java屋の会社に入った新入社員」
「bbs.cgiスレでMySQL化を言い出す奴=オープンソースWebASPを聞きかじった新入社員」

XML化してもハードウエアには優しいかも知れんけど、トラフィック的にはそうでも無いんじゃないの？

XMLの構文解析処理って結構重いんじゃないの？

libxml2をincludeしてソース書いたことあるか？

parser自体まともじゃないのもあるけどな

>>955
ちょっと要領を得ないのだけど、XML化したとして、そのparseはクライアント側が
やるんでしょうか？XMLをブラウザに丸投げしてブラウザが解釈？
だとするとクライアントの互換性が問題になってくると思う。

サーバーがparseするんであれば、その負荷が馬鹿にならないと思うし、
(Parser作ったことある人なら分かると思うけど、複雑な構文を殻に使った
入れ子のparserってかなり負荷大きい)結局read.cgiがベタデータをparseするのと
何も変わらんので、むしろ負荷は大きくなると思う。

あと、datの容量が減るというのが良く分からないのはどうして？
>>953の形式の方がディスクのリソース食いそうだけど。

ちとXMLについてはほとんど無知なのでおかしな事言ってたらｽﾏｿ。

>>965
同意。

>>950
ネタじゃなくてマジだったのかよｗ。レスついてるしネタにしとけばいいのに

>971
ひろゆきｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!
>957=root氏
今のスレは現在のbbs.cgiを使用して、
新スレは新しいbbs.cgiを使用すれば大丈夫だと思われ。
そして今のスレが全部落ちれば、XMLを本格運用すれば(・∀・)ｲｲ!!と思います。
他のメリット・デメリットにに関して・・・現在調査中。
>970全てクライアント。
互換性：デザインはCSSを使用してるので互換性は問題なし！！
datに付いてる<>←これが不要になる。
<a href="">〜</a>とかHTMLでは必要だけど、XMLは<mail>〜</mail>形式でGJ。
ログも読みやすくなる。(正直、今のDATは見にくい。)
read.cgiの容量も軽くなる。→鯖の負担も軽くなる。
専ブラがどうとかこうとか→実施の一ヶ月ぐらい前に、専ブラの作者にメールで通告。
>967重くなるのはクライアント側。けど体感速度は変わらない。
以上です。

なんか真性くさいなあ。
> datに付いてる<>←これが不要になる。
これﾁｮﾄﾜﾗﾀ

>>973
>>他のメリット・デメリットにに関して・・・現在調査中。
そういうのを調べた上で提案するんだろアホか
つかプレゼンした時あるの？

本気で言ってんですかねぇ。
実際に>955の例とDATのサイズを比較してみたことがあるんかな？
XMLやCSSに対応していないブラウザとか持ち出したら「主要ブラウザで
見れれば問題なし！」とか言うんだろうな…。

本７？

>975
DATより軽い等
既出のメリットだけで良いかなぁと思ってやった。
今は反省している。
>976基本的にHTMLと同じだっつーの。

XMLにすると、一般ブラウザ利用者が多ければメリットになりそうな気がするが、2chブラウザにとってはデメリットしかないんじゃないのか。
とにかく、datのファイルサイズが増えるのは確かだと思う。

>979その辺を何とかしてみようかと。

>>977
ﾜﾛﾀ

>>978 若いねぇ。
>955 のXML部分を拡張子htmlで保存してWebブラウザで開いてみなされ。
その表示でおまいさんが満足できるなら何も言うまい。
で、DATよりディスク容量をくうのは理解できた？

クライアント側でparseプラットフォーム汎用って言うとJava2のXercesに落ち着いてしまうわけだがどうよ。重いんじゃね？

いっそ全部preタグでくくってテキスト出しという手もあるなぁ。
文中のURLとか意味のありそうなとこは専用ブラウザが上手に解釈してあげると。

んでもAAがボロボロになっちゃいそうな予感ｗ

>>984
preタグだけはやめてくだされー
by au使用者

あのさぁ
すでにクッキーの仕様がIE以外無視でしょ？
主要ブラウザとか以前の問題じゃないかしら。

上で出てるけど俺も個人的にXMLに移行する理由がないと思います。。

まずはこのスレッドや運用情報板のスナップショットをXML化してどっかにアップしてみるとか・・・
サイズの比較とかもそれで一目瞭然と思うわけだが(^_^;)

ま、XML化する必要があるとは思えんけどね(^_^;)

(^_^;)

>987
壷が使えなくなるのが嫌だってキッパリ言えばいいのに

XMLのデメリットはサイズの肥大化だよ？
2chみたいにフォーマットが決まっている場合、
データ項目の変更も無いし、datで十分だよ

>>990
あと、XMLは構文解釈が面倒だしコストかかるから、datの汎用性がなくなると想う。
今の形式はPerlなんかでもさらっといじくれるのが魅力なわけで。

やはりdatの場合は<>SVが効力を発揮する場面でしょ。最近のエンジニアは何でもRDBに
突っ込んだりXML化するのが好きな人多いけど、結局コストが掛かって固定長や
CSVの方がよっぽどマシだったってケースも存在するんだよな。ちょっと愚痴。

テンプレでつ（建てた方がいいのかな？
─
peko鯖の稼動によりボトルネックの一つである事がより明らかになった
bbs.cgi作り直しプロジェクトです。

【開発環境の工事現場】
また挑戦。＠2ch掲示板　　http://dso.2ch.net/myanmar/
また挑戦２。＠2ch掲示板　http://dso.2ch.net/yangon/

関連スレなどは >>2-5 くらい
─
【関連スレ】
【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part17
http://qb5.2ch.net/test/read.cgi/operate/1107376477/
read.cgi再開発スレ Part2
http://qb5.2ch.net/test/read.cgi/operate/1105909861/
◆ 全サーバトリップ統一作戦
http://qb3.2ch.net/test/read.cgi/operate/1067245837/
bby -- スレッド情報一元管理システム構築スレ2
http://qb5.2ch.net/test/read.cgi/operate/1086868799/
【広告・宣伝】Rock54【自動排除】　4
http://qb5.2ch.net/test/read.cgi/operate/1083063122/
─
【前スレ】
bbs.cgi 再開発ﾌﾟﾛｼﾞｪｸﾄ
http://qb3.2ch.net/operate/kako/1053/10530/1053067870.html
bbs.cgi再開発プロジェクト２
http://qb3.2ch.net/operate/kako/1069/10691/1069144193.html
bbs.cgi再開発プロジェクト３
http://qb5.2ch.net/operate/kako/1076/10766/1076666901.html
bbs.cgi再開発プロジェクト４
http://qb5.2ch.net/operate/kako/1101/11019/1101984763.html
bbs.cgi再開発プロジェクト5
http://qb5.2ch.net/test/read.cgi/operate/1103495887/

サイズを気にしてるなら今のdatも作り直したほうがいいんでない？
このスレのdatを適当に削ったら一割以上サイズ減らせたし。

現行のサイズを気にしてるんじゃなくて、現行よりサイズが増えるのを気にしてるんでしょ。
rootが書いてるように作業量に対してメリットが大きければやるでしょ。
1割減らすメリットが充分大きければやるかと。

とりあえずアンカーにリンクつける必要ないんじゃない？
↓これ生成するときにつけたらいいのでは？
http://qb5.2ch.net/operate/html/1103495887.html
どうせread.cgiでは変換するんだから

名前がデフォルト名無しさんの場合はDATに書き込まず、
表示するときにSETTING.TXTから読んで付けるようにしたら？
結構削減されるような気がスルですが。

それ言うなら日付を元に戻すのが先決かと

そろそろ次スレか
立ててみるかな

次スレ
bbs.cgi再開発プロジェクト6
http://qb5.2ch.net/test/read.cgi/operate/1113117347/

↑乙。そして1000。

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。