gikozilla

monazillaとは独立に２ちゃんねるに関連するプログラムを作るプロジェクト。

まず、gikozillaのミッションを定義しなければならない。

・連続カキコ可能
・スレ乱立可能
・100回/sリロード機能

以上

・あくまでオープンソース
・2ch UA 作成のためのライブラリ/フレームワークを提供する
・言語は主要ないくつか（C、C++、Java、Perl、Delphi、etc）

Ruby!

monazilla.org に行った。
既に gikozilla が開発されている模様。

じゃあまずはプロジェクト名から考えないとな。

・ライセンスは BSDL や Perl's Artistic、AS IS を推奨

いやそのまえに、点呼だ。gikozillaの方針に賛同する
(あるいは、monazillaの方針に反対する）ヤツ、何人いる？
０！(漏れは傍観者)

それよか方針って何だ。

改造計画とやらが全部明らかになるまで様子見

>>9
>>3-4

クライアントサイドのオープンソースプロジェクトも興味深いが、
そろそろサーバサイドのオープンソースプロジェクトをはじめてみないかい？

オレが考えているのは、当面 2chのラッパーとして機能するプロクシサーバ。
圧縮状態での差分取得や、共通フォーマットを厳密に規定する。
今は 2chと言ってもサーバによってデリミタが違っていたりとか
クライアントで吸収しないといけない差異が多すぎるでしょ？
そういった差異などをプロクシサーバが吸収し、規格通りのレスポンスを
クライアントに返す。クライアントは非常に作りやすくなると思うんだ。

まぁ、プロクシを作るために2chの解析は続けないといけないんだけどさ、
クライアントごとに対応するより、一箇所にマンパワーを集中させたほうがいいだろ？

こんなプロクシ書きのオレでも gikozilla に混ぜてくれる？

つか、gikozillaの主催者/中心メンバってだれやねん？

「デフォルトの名無しさん」

>>12
素晴らしい。

>>12
２ちゃんねる取得用のDLLをひとつ用意して、みんなでそれを利用する、
２ちゃんねるが仕様変更したらそのDLLだけ修正すれば済む、って話か？
違うか。

>>16
違わない。彼はそれをサーバ側でやるのはどうかと考えている。

>>12 gikozilla というよりも monapache か。 面白そうだ。

>>16
分かり易い説明ｻﾝｸｽ。
漏れの頭では>>12の逝ってることが理解できんかった。

むしろ、gikogate

>>12
素晴らすぃ！
つっても、2ch自体はサーバ差異を無くそうとか動いてたりはしないのかな？
スクリプト差し替えとかしてるんだからやってそうなもんだけど。

>>19
いや、ちょっと違うらしいぞ。鯖立てるらしいぞ。
俺としては共通DLLも作ってホスィ

2chがひろゆきの個人サイトってことを忘れてないか？
サーバ側をどうこうできるわけないだろ。俺らはクライアントのみ。

ん、違うのか？
サーバ立てるって、2chの負荷に耐えるだけの設備をどう揃えるんだろ？

>>23
proxy なら出来るだろ。２ちゃんから見ればクライアント。
実際鯖立ててくれる奴がいるのか知らんが。

個々のライセンスに従って　monazillaのコードを利用するのは可ですか？

>>12
とても良いと思う。
俺のチンカスのような力でも何かできることがあれば協力する。

UNIX板の奴らも言えば協力すると思うよ。

＞12 ＝ http://pc.2ch.net/test/read.cgi/tech/1005282763/443n だね

monazillaを反面教師として、開発に関する情報はオープンにしていこう。参加者と非参加者の垣根をできるだけなくそう。
決してコテハンの馴れ合いにはならないように。

オープンソースプロジェクトって誰かが一人である程度まで完成させないと
盛り上がらないんだよね。

>>27
何だその言い方？
UNIX板の人は全員あんたの子分なのか？

>>31
スマソ、言い方がなってなかった。
あくまで、憶測なので・・・。ごめんなさい。

>>31
いちいち狂犬のように噛みつくなよ。

２ｃｈ⇔gikozilla(gikogate)⇔ユーザー

>>4
>・あくまでオープンソース
>・2ch UA 作成のためのライブラリ/フレームワークを提供する
>・言語は主要ないくつか（C、C++、Java、Perl、Delphi、etc）

>>29
>monazillaを反面教師として、開発に関する情報はオープンにしていこう。参加者と非参加者の垣根をでき
>るだけなくそう。 決してコテハンの馴れ合いにはならないように。

誰かまとめて。

どこにCVSを置くかな。
それより、プロキシサーバは何で書くの？

■■　gikozilla(gikogate)プロジェクト

■基本理念
・オープンであること（いろんな意味で）

■概念
・proxyサーバを立ててここにgikozilla(gikogate)モジュールを入れる。
・外部よりこのモジュールへは自由にアクセス可能。
・言語は主要言語（C、C++、Java、Perl、Delphi、etc）

>>36
Ruby!

■基本理念
・オープンソースの理念に基づき、2ちゃんねるに関するプログラミング技術を共有する。

はどう？

基本理念：
2chのさーばーをオープンソースにするため、聖戦を執り行うこと。
プログラムに適用するライセンスはGPL以外許さん。

追加
■基本理念
・コテハン同士（高技術者同士）の馴れ合いにはならないように

gikozillaとgikogateって名前で決定なのかはわからないけどさ、>>37はgikozillaの中のgikogateプロジェクトってことで、gikozilla全体ではこれに限らず、2chに関わることはいろいろ広く受け入れていくのがいいと思う。
それともあんまり最初から間口を広げすぎると収拾がつかないかな？

>>42
それは自由（フリー）。

企画考えました。

web.archive.orgを２ちゃんねるのログのストレージとして使えないかな。

たとえば、
http://piza2.2ch.net/tech/kako/998/998908559.html
は、既に
http://web.archive.org/web/20011231042427/piza.2ch.net/tech/kako/971/971960169.html
保存されている。　

極端に言えば、このページは2ch.netのサーバに保存する必要はないし
プロクシを作るなら web.archive.orgに飛ばすことで転送量を減らせる。

あ、URLのコピペに失敗している。

たとえば、
http://piza.2ch.net/tech/kako/971/971960169.html
は、既に
http://web.archive.org/web/20011231042427/piza.2ch.net/tech/kako/971/971960169.html
保存されている。　

に修正。

>>43 つまり

　　　→　　web.archive.org
　　↑　　　　　↑↓
２ｃｈ　　　　　proxy　→　ユーザー
　　　　　　　　　　　　←

こういうこと？

えと、2ちゃんねるがdat直読みできなくなりそうだから、2chのHTMLをもう少し
プログラムから読みやすい形式に変換して提供するproxyを提供しようという話?

もしそうならXMLで提供してほしいな。

..しかし、有料化のからみでツブされたりしないかね? 細かい話だけど、各発言
の著作権はだれにあるんでしょ。

素晴らしい。
漏れも傍観者に立候補するYO!!

ユーザー　
↑↓
proxy　←→　2ch.net
↑↓　　　　
web.archive.org

まぁ、検索に時間はかかるわけだが、既に更新されることのないログなのだから
多少は我慢してもらう？

proxyサーバ内に保存すればと言ってみるテスト。

web.archive.org を直接使う場合との差異は?

上の図だと、ユーザがデータを得るのにproxy経由でweb.archive.orgに
つないでる感じなんだが。
だったら、proxy内に保存しておいてそこからGETしたほうがいいんじゃ？

アーカイブ済みのURLのリストをproxyが持つのは大変かな？
どれくらいあるのだろう？

web.archive.orgってどの程度そろってるの？
それにかなりレスポンスが悪いような。
有志が過去ログサーバをいくつかミラーリングした方が良くない？

ちょっと前まで、アニメ板なら全ログ持ってたんだけどなぁ（藁

proxyの回線がパンクしないか?
2chの全アクセスのツール分が来るわけだから

仮にgikogateが2chに認証するようにすると、
ライセンスは1つでよいとか
それは管理側が許さないだろうな

>>55
ライセンス結んで開発を行うととクローズな開発にならないか?
monazilla を反面教師としてやるなら、ライセンスなど結ばずに開発あるのみ。
monazilla ソフトを解析したりパケット眺めたりしてやるしかない。
samba みたいに徹底的にエミュレートしてあげればいい。

IEのエクスプローラバーに入るのがあると（・∀・）ｲｲ！なぁ。

ソフトウェアの面はよいとして、問題はそれを置くサーバだなあ。

どれだけ負荷がかかるか予想立てられる人が居ますか？
また、その負荷に耐えられるサーバを用意出来る人は居ますか？

そのサーバには、NNTP<->2chGatewayもついでに置かれるという罠。

どこかにサーバを立てるとなると、将来的に負荷は相当なものになるだろうな…
クライアント−proxy間はHTTPを捨てちゃえば少しはマシになるかも。（それってproxyって言わない気が）
ま、proxyをローカルに置いてもらうって選択肢もないことはないし。
gikozillaとしてのクライアントAPIを策定するだけでも意義はあるよね。

>>36
read.cgi がある cvs 鯖とか。

おっ。意外とプロクシ反響あるんだね。

>>46
プロクシ作るとしてレスポンス規格が厳密にするけど、いくつかのプロファイルを用意したいなと思う。
PC向けクライアントを作るのなら XML で返すというのも非常に意義のあることなんだろうけど、
オレがそもそもこの考えに至ったのは PDA で2chクライアントを書こうと思ったからなんだ。
PDA だとさすがに XMLパーザ載せる/作る の辛いじゃない？

>>49
プロクシサーバにログを保存するというのは、(オレは)考えていなかった。
そうすると、ストレージ面で 2ch相当の設備がきっと必要になるからだ。
キャッシュという概念くらいなら盛り込めたらパフォーマンスあがるだろうね。

>>22
オレは共通DLLは考えて無かった。オレ自身がマイナーなPDA向けにクライアントを
書きたかったということもあり、プラットフォーム依存性には敏感になっていたんだよ。
それで、共通DLLではなくプロクシという提案をしている。

それと、負荷を気にする声が多いけど、オレは楽観的に考えている。
だって、このプロクシには monazilla のツールやブラウザは接続しないんだぜ？
一般ユーザーは、かちゅ〜しゃ使うって。このプロクシに繋ぎにくるのなんて
ここでオープンうんぬん騒いでるオレ達だけなんだからさ。きっと。
それにストレージ面での心配がなければプロクシサーバをいっぱい動かすのも
容易じゃないか？ いろんな人のいろんなサーバで動かせるはずだよ。
実際そうならないと、2ch側の個別規制をくぐりぬけられないと思うし。

巨大掲示板のオルタナティブとして生まれた2chが王道にたった今、
オレらが 2chのオルタナティブとして生きていこうじゃないか。
オルタナティブとしてのおもしろさ続けていこうな。

やる気マンマンの>>12がいるスレはここですか？
よーし、じゃとりあえず点呼しよう。
０！(漏れも>>8に続いて傍観者)

あー、やっぱ誰でも考えることは同じですね(ｗ

gikozilla 用に、よくあるタイプのレンタルサーバを
月額 3k〜4k ぐらいで確保しちゃうのも手ですよ。
MySQL + PHP あたりで必要なコードを書いてしまって、
外部からは HTTP 経由で CGI 呼び出しのようにしてアクセスする、と。
一部では月額 10k ぐらいでまるまる一台確保できるところもあるみたいですな。

あと、30秒に一回とかそれぐらいの割合で 2ch.net をポーリングするとか。
こうするとクライアントから 2ch.net には書き込みだけすればよくなります。
バランス調整次第では、PointCast もどきにできるはずです。

その鯖レンタル代誰が払うの…。
proxy使用者に負担で2chと同じ結末？

>>65
私ゃ持ち出しでやりますよ。
転送量が、とかいう話になったらやめるだけの話。

んにゃ、266さんが来た、つーことは P2P project も絡んでくるのかな。
過去ログ消されてもこれで安心？

>>67
いや、横やりだけ。
こっちもこっちでサーバ構えて色々やるつもりなので。
ネタ出しとかテストへの協力とか
そういう面では何かしらオファーできるかもしれません。
なま暖かい視線を送り続けるということでよろしく。
邪魔にならないよう、もう原住スレに戻ります：）

動作が同じであれば proxy が複数あってもいいんじゃないか
ということは複数の無料鯖集めれば済む話かと

できるだけ負荷分散したいからcgiフリーな鯖であれば
置けるくらいの動作仕様が望ましいかも

やっぱりgikogateも2chから規制されるような気がする…

>>70
>>62ぐらいの規模なら、規制する理由はないでしょう。
普通のブラウザで読むのと変わらない程度の負荷なら問題ないと思います。

>71
＞あと、30秒に一回とかそれぐらいの割合で 2ch.net をポーリングするとか。
こういうことするなら、
>普通のブラウザで読むのと変わらない程度の負荷なら問題ないと思います。
とは思えないんだけどな。

とりあえず、PC鯖だけポーリングするとか。
と記念カキコ

早く作れよ

なに言ってるんだよ。こうやって考えてるだけが楽しいんだろ。
このスレってそういう趣旨みたいだし。

>>75
えっ？作らないの？？？

順序よく作っていくんでしょう。
急ぎすぎ。

作らないよ。つーか作れない。
だって俺たち、ギコジーラだもん。

♪ぎーぎーぎーぎこ ギコずぃ〜らぁ〜 ギコっ！！

gikozillaが出来る前に２ちゃんが崩壊してるのに1000ダカット。

[[[[[[[

>>78
えっ？作れないの？？？

つぎはしぃじら？発音しにくひ…

monazilla開発ゴッコ関係者が暴れてますな。見苦しい・・・。

>>83
発想が浅い、無効！！

monazilla開発者が暴れてますな。見苦しい・・・。

monazilla開発者が暴れてますな。見苦しい・・・。

monazillaが暴れてるんでしょ？

monazillaが暴れてますな。見苦しい・・・。

monazilla開発ゴッコ関係者が暴れてますな。見苦しい・・・。

誰かがMonazillaスレで逝ってたけど、
本当にGNOMEとKDEの関係になりそうで怖いな。

今までソースを公開してたソフトがまた公開を再開したら漏れ的にはmonazillaで文句ないんだけどなー

誰かが裏でシコシコ作ってるんだろなぁ

とりあえずproxy開発するんですよね？

　　　　　　　　　　　　　　☆ ﾁﾝ　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ〜
　　　　　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ〜
　　　 　 　 ☆　ﾁﾝ　　〃　 Λ＿Λ　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）　＜　　ねぇねぇまだなの？早く早く〜
　　 　 　 　 　 　 ＼＿／⊂　⊂＿ )　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 　 　 　 　 ／￣￣￣￣￣￣ ／|
　　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　　|　 長野りんご. 　 |／

Monazilla は２度死ぬ
Gikozilla　はすでに死んでいる

嫉妬レスが目立ちますね。
君らも参加したら？

>>96
・・・・・

>>64
13Kでまるまる１台借りれるところで借りて、
datキャッシュサーバのようなことをやりましたが、
datファイルが１ヶ月で6G近くたまります...ので、
かなり難しいことだと思います・・・。違ってたらごめんなさい。

>>98
そんなにたまる？
２ちゃんの場合、板が１００、それぞれスレッドが６００あるとして
書くスレッドの上限が512KBだから、全部埋まったとしてで30GB。
（;´Д｀）

>>12
server side で2ちゃんねるのHTMLを加工するって話だったら、おれも3日前に
ちょっと似てるの作りました。 http://moso.borogrammers.net/newlin/
←これ。

2ちゃんねるに書き込まれた発言のうち、URLだけを流し読みするためのサイトなん
だけど、数十分ごとに2chをポーリングして(index.htmlだけ取得)、サーバ側で
HTML -> 俺スキーマなXML に加工して蓄積してます。ソースコードも全部おいて
あるのでよかったら御覧くださいませ >>12 さん他。

とりあえずproxyとなるとサーバ借りたり大変だと思うんで
cgiとして実装してみたら？クライアントから見てAPIが
規定されているだけでも非常に便利だとは思うんでね。
オープンがどうのってのは良く分からんけど、
サーバーの差異を吸収というのは是非やって欲しいと思った。

>>100
xmlはどのくらいの割合で増えますか？

>>100
ちと書き忘れ。

何が言いたいかというと、2ちゃんからdat直読みできなくなっても、サーバ
サイドで、クライアントからの要求に従ってリアルタイムに、HTMLからdat
(に近いもの)を生成するのは結構簡単なんじゃないかと。それだけ。

俺は、>>100のヤツはXSLTで書いたんですけど、ソースコードはかなり小さいです。
正規表現が使えるXSLTプロセサをサーバサイドで使えるなら、もっと小さくなると
思う。

参考: http://www.exslt.org/

>>102
いまんことwatchしてる板が少ない（というか基本的に俺個人用なので増やさないつもり)
ので、3〜4MB/day です。

×いまんこと
○いまんとこ

たまってますね（ﾜﾗ

本題・・・
オープン（全板取り込み）にしたら、60-80Mb/day位ですかね？
とすると2GB/monthくらいかな？
ささえきれるかな？

proxyだったら溜め込む必要ないでは？

つかさ、
何をやるにも２ちゃんねる側の負荷やら転送量を気にしながら
作らなきゃいけない現状ってのがやっぱり異常だと思うんだよ。

だから、proxyってのはいい案だと思う。proxy側でキャッシュ
すれば２ちゃんねる側にはproxyひとつがアクセスする分だけの
負荷と転送量しかかからないし。全部キャッシュするのが
難しければP2Pを導入すれば負担も少なくやれる。
是非、実現して欲しい。

いまでてる話って変換プロキシーじゃないの？
２ちゃんのキャッシュプロキシー作るなんて無謀だと思う。

>>105
ｶﾞ━━━━(；ﾟдﾟ)━━━━━ﾝ
溜まってます（ﾜﾗ

>>107
同意。そのサーバのディスクの空きに応じた量だけキャッシュ、
ってproxyは良い案だとおもいます。

squid みたいにして散らせば負荷分散になるしな

p2pとうまく折り合いつけられたら
すごいことになりそうな気がする…

ひとつの公式見解がでてきました。
http://pc.2ch.net/test/read.cgi/tech/1005282763/541-

Monazilaと対立するしないは別として
P2Pと組んでやって見るのがよさげだね

NGのっとり計画。。。

で、どうよ？

んで、proxyサーバのキャッシュをキャッシュ取得するたびに、
NGに流しまくるってのはどうよ？

>>112
寛容な見解、ありがたいですね。
感謝。

それよりMSNメッセンジャーを乗っ取りたいな。
予め必要スレをProxyに登録しとくと、キャッシュが更新される
たびに、MSNメッセンジャー経由でメッセージが届くとか？
２ちゃんブラウザ側でMSNメッセンジャーのプロトコルに対応
してくれれば、「見に行く」から「届く」になるから、便利そうだと
思うが、どうよ？

>>118
今以上にどうでもいいレスが増える（ｗ

まー確かに、大量の宣伝書き込みが嫌ってほど届く可能性はある（ｗ

DM会社は大喜びだろーね！（ﾜﾗ

>>118
MSNメッセンジャー直狙いはともかく、proxy側からクライアントに
pushする仕組みは整えておくと便利かも。

じゃあ /.J も

２ちゃんブラウザの自動巡回機能でスレ取り込み、それをメールなり
ニュースなりMSNメッセンジャーなりへ投げるってのは、それほど難
しくなさそう。
でも、これを個人個人が行うと自動巡回の負荷が掛かるしな・・・・

＞proxy側からクライアントに pushする仕組みは整えておくと便利かも。
SSTP-botを思い浮かべてしまった‥‥

可愛いキャラクターが、２ちゃんの書き込みを台詞として表示！
逝ってよし、ハァ？、氏ね、回線切って首吊れや！等、２ちゃん用語連発
萌えますな（笑

>126
わしの扱いをどうするかが問題やね。

質問した者です。ひろゆき、ＯＫくれたよ。
あーよかった。で、次は仕様固めだな。

・共通フォーマット
・ログのキャッシュ
・P2P化
・push
・２ちゃんねるへのアクセス方法

決めるのはこんなとこか…？
上から順に重要度高しかね？

まずは言い出しっぺの>>12の意見を聞きたいところ。
266さんのprojectととも協力したいが、もう無理かなぁ

クライアント−proxy間はセッション張りっぱなし(httpステ)
スレに更新があったら、差分だけクライアントに送る。
サーバを分散してそれぞれやりとりすればまさにIRCライクに！

もはやproxyでも何でもないな（ｗ

>>129
ｲｲ!
IRCクライアントがそのまま使えたら天国だな（ｗ

まぁ、proxy っつても、http proxyつくるとは誰も
思ってないっしょ。

数千セッション張りっぱなしなデーモン書くのは、、運用方法も含めて
安定させるまで一苦労だよね。ircd見てても。

でも夢があっていいな。賛成>>129

1つの鯖が数千セッション張らなくても、それこそ疑似p2pで
管理・分散する方法をとればいいとおもう。

>>128
ファイアウォールの中にいても使えるようにしてくれると幸せ。
P2P機能を取り入れるなら特に。
常時接続でルータ外すわけにいかないユーザーもいるし。

>>133
FTPのPASVのような、どっちがポートを開いて待ち受けるか決める
調停機能があればいいのかな？

火壁内クライアントＡ：そっちでポート開いてほしいんだけど、どうよ？
火壁外クライアントＢ：ＯＫ！8088へ繋いでよし

火壁内クライアントＡ：そっちでポート開いてほしいんだけど、どうよ？
火壁内クライアントＢ：ハァ？
火壁内クライアントＡ：氏ね
火壁内クライアントＢ：オマエモナー

といったやりとりをさせればいいのかな？

ircいいねー
ircdには既存のものをつかって、
proxy<->間のデータのやりとりは
botにやらせれば開発コストも低い

スレッドをチャンネルに対応させるといいか。

proxy<->クライアント間のインタフェースが決まれば
いくらでも拡張できるな。

で、誰が鯖立てて、誰がproxyを書くのよ。
クライアントなら俺も手伝えるけど。

>>134
だね。
P2Pって基本的な技術とかよく知らんのだけど
火壁内to火壁内の接続でも
うまく解決してくれるようにしてくれると幸せだけど
さすがにそれは難しいか...（串鯖に中継させる？）

いちどポシャったかと思ったが112から一気に息を吹き返したな。

http://pc.2ch.net/test/read.cgi/tech/998915621/
この辺とかってなにか参考になるのかな

なんか大きな話になってるねぇ。

>>129
むずかしくない？ クライアント - プロクシ間の転送効率と即時性を
あげたいというのは分かるんだけど、そうするとプロクシが
２ちゃんサーバに対してポーリングを行うことにならないか？

P2Pな方向に進むとストレージ面で苦労しそうな気がするし。

オレは >>101 の意見は目からウロコだった。オレがやりたかったのは
クライアントに対するAPIの共通化とそのオープン性の維持だったからさ、
そーいわれりゃ、CGIでも実装できるな、と。

事実、オレにはサーバを無料で借り受けられるようなバックグラウンドや
コネなんてないからね。でかい事言ってすまん。

とりあえず、>>128 がまとめてくれた項目で オレが考えていたのは
・共通フォーマット
だけなんだ。だからオレ的都合でここから話をはじめていいかい？

ここを決めて、適当にコンバートCGI書いちゃえばクライアント開発に
着手できるはずだからね。規格に則ったクライアントが増えれば
レスポンスなどの向上のために proxy立てようとか、裏でキャッシュしとこうよ、
とか話が膨らむ(かもしれない)だろ？

サーバサイドの仕組みをおおげさにすると実装に時間がかかりすぎるから、
共通フォーマットを制定して クライアント開発とサーバサイド開発を
平行して進めていくのがいいんじゃないかと思う。

どうも　兄ちゃんねると言うサイトをやっています。
せちがないにぎりめしと申します。
皆さん　とても開発熱心で　しかも僕にはわからない言語が飛び交っていまして
？が百個ぐらい頭の上にある状態なんですが
最近HPが重くなってきたものですから
何とか専用サーバーを入れたいなーと思いまして
相手の企業にビジネスプランを提供する代わりに専用サーバーを手に入れようか…
などと考えているのですが　いかんせ自分にプログラムの知識が無いので色々と協力してくださる方々を探しているのですが
みなさんはやはり　2chの為のツールしか作成されないんでしょうか？
それとも　他のサイトにも協力していただけるんでしょうか？

>>140

そっちで、これから決められるであろう共通フォーマットを出力して
くれるんなら多分、"Gikozilla対応"のクライアントからは読めるよう
になるんじゃないかな。…そういう話じゃないのか？

>>139
そそ。ポーリングになっちゃうよね。そのへんはちょっとつらい。
やっぱり重要なのはAPIだね。これさえきっちり決めておけば、proxyもクライアントもどういう形で実装してもOKだからね。
>>140
APIさえ統一されれば、他のサイトにもいくらでも適用できまっせ。

ふが…
む　むずかしい　言葉が…
僕にわかる言葉で言うと空のサーバーに　今までの物と互換性を持たせつつ
P2Pとか　なんか話して見えたプロキシですか？
そういう物が動く環境を優先して掲示板を作ってもらえませんか？
となるんですが…

>>141-142　ということは
このスレッドの前の方に書いてある事を元に互換CGIを準備したら
そちらで開発した物で兄も見えますよ…　って事で良いんでしょうか？

>そういう物が動く環境を優先して掲示板を作ってもらえませんか？

おまえ、このスレ出入り禁止。

お風邪などひかれませんようにお体に気をつけてがんばって開発してください。
すれ汚し申し訳ありませんでした
お邪魔しました。

すいません
兄ちゃんねるで>>143が誤解されてるのでは無いかと怒られまして…
そういうものが動く環境を、（兄ちゃんねるに）優先して作って欲しい。
こういうつもりで言ったんじゃなくて
環境を優先して、掲示板を作って欲しい。
というつもりで　あの　皆さんの開発ツールの実験というか
皆さんのアイデアのツールを動かす為のといいますか
そういうつもりだったんです。

コチラの勘違いでしたらたびたびすれ汚し申し訳ありませんでした。
しつれいします。

>>140 >>143 >>146
これかい？

http://ani_ch.tripod.co.jp/

内部フォーマット(データ保持)はどうなっての？

正式にはそっちじゃなくて
http://www.i-love-you.gr.jp/suball/index.cgi?ID=1
こっちになります。
現在の状況としては17氏のスクリプトにちょっと手を加えた程度の物になってます。

proxy の詳細は不明。
ただの変換　proxy　にするか、キャッシュを取るか、
さらにP2Pを付け加えるか（負荷軽減）、さらにさらに
もっと便利な機能を付け加えるか、
どうなるかは、まだ決まってないよ。

だからとりあえず、共通フォーマットを策定するして
それ用の専用クライアントを書こうか、という話。
ここの部分は proxy がどうなろうと変わらんから。

で、具体的に兄ちゃんねる向けに何をして貰いたいの？
専用クライアント（まだ出来てないけど）で読むだけなら、
共通フォーマットを出力して貰えば対応できます。

>>144
こらこら。出入り禁止とか言うなって。

>>149
フムフム　てことは　CGIとかサーバー側はまったく無関係で良いという事でよかったでしょうか？

てっきりサーバー側にも専用の設定とか組み込みとかして動かす物だと思ったの物で
そのあたりの実験がてら　そういう物を動かすという視点から見た掲示板をつくらないと逝けないのかなーと
思った物ですから
サーバー移動に伴ってシステムの組みなおしを検討していた物ですから
どうせなら僕みたいな内部の処理に関しての構想が無い人間よりも
内部の処理面でいろんな企画考えて見える方が作られた方が良いのかなーと思った次第です。

ですので　特にこれをお願いしたいとかという部分があるわけでも無いんです…
普通のCGIを組んで下さいなんて言えませんし…

どう言ったらいいかわかんないんですが
皆さんが新しいネットワークのシステムの構築を目指してみえるような気がしたので
実験といいますか…
実用してみるのに使ってみて頂けたらありがたいなと…

Gikozillaはいわば、２ちゃんねるの外に覆い被さって（本体の
改造なしに）、もっとプログラマに便利に改造しちゃおーという
プロジェクトなんです。
ちゅーわけで、ちと誤解があるかな。

>>153
了解しました。誤解してたようです。
すいません失礼しました。

>>140
考え方によっちゃチャンスかもよ？
ここでgikozillaに参加しておくと標準板リスト？に兄ちゃんねるの板も
含まれるかもしれないじゃん。別にgikozillaは２ちゃん専用の
ラッパーである必要はないんだろ？ ２ちゃんも兄ちゃんもその他掲示板の
ラッパーもgikozillaとして取り組んで共通フォーマットでクライアントに
提供できたらすげ−ことなんじゃねーか、と思った。

まぁまぁ、まだフォーマットも決まってないのに…
とりあえず、始めよう。
俺はXML形式がいい。でも、CSV形式の方が手軽でいいかな？

>>155
ありがとうございます。
確かにありがたいチャンスですねー
ただどうせシステム入れ替えるならというのもありまして
他の掲示板上で出来ない事が出来るというネタを仕込みたいんですが
そういう掲示板オリジナルのシステム部分についてはやはり共有型のソフトだと切られる事になりますよね？
書き込み等は他のとそんなに変わらないんですが　やはり書き込みの時の処理で独自なのがあると不味いんでしょうか？
それとも書き込みのCGIとかのソースを公開しておくで対応して頂けたりするんでしょうか？

質問ばかりで申し訳ない

>>140
「gikozillaに参加しておくと」というのは「君自身が兄チャンネルの
gikozillaラッパーを書くと」という意味だ。酷な言い方だが、多くの開発者は
２ちゃんねるを読み出したいという欲求は持っていても、兄ちゃんを読み出したいという
欲求は持っていないだろう？ だから他力本願だと実現は難しい。
「対応して頂けたり…」なんて言ってるようじゃ相手にされないよ。

兄ちゃんねるに関してラッパーを書くのは >>140 自身だ。
チャンスだと言ったのは gikozilla対応掲示板を謳い、
さらに何かの間違いでgikozillaが世間に認知されるようなことになったら、
gikozillaユーザーにとって「２ちゃん」も「兄ちゃん」も同じ存在になる、ということだ。
決して「誰かが開発してくれるかもよ？」などとは言っていない。

>>140 がんばれ！

>>157
板一覧、スレ一覧、書き込み内容が効率的に取得できれば、他はどんな
フォーマットでも構わないと思うよ。

板一覧に必要な情報
カテゴリー名、カテゴリーに所属する板名、カテゴリーに所属する板を識
別できる何か(2chの場合は、鯖名とディレクトリ名が使用されてる)。

スレ一覧に必要な情報
スレ名、発言数、スレを識別できる何か(2chの場合はユニークな番号が
使用されてる)。

書き込み内容に必要な情報
書き込み時間、書き込み者名、発言内容

フォーマットはCSV形式の方が扱いが楽だと思うけど、XML化するメリット
ってなんだろう？

スレ一覧などはバイナリイメージでの取得ｷﾎﾞﾝﾇ

typedef _thread_list {
　char[10] index;
char[96] name;
char[32] host;
char[32] path;
} ThreadList;

取得したデータを (ThreadList*) にキャストしたら即利用可能｡
parse？ﾅﾆｿﾚ?ｶｯﾀﾙｲﾖ｡｡｡

>>160
ちょっと前時代的すぎ

とりあえずフォーマットはsubject.txtと*.datだと仮定してみる｡
そいでもって改善ポイントを出して行こうや。

・書きこみ単位にシーケンス番号が付いてると嬉しい｡

…これしか思いつかんかった｡あとはリクエストも決めないといけなんだよな｡
データの差分取得したい時はどうやって要求範囲をリクエストするのか､とかだな｡

>>156
ｽﾏｿ。漏れもXMLにするメリットがよく分からん。
できれば詳しく説明をｷﾎﾞﾝﾇ。

>>163
こんなところじゃない？

1)文字コードだとか固定長か可変長かとか細かい仕様を考えずに済む。
2)パーサーを使えば取り扱いが比較的容易。
3)スキーマで検査すればエラーチェックも容易。
4)フォーマットの拡張も比較的容易と言えば容易。

つまりはそれなりに楽。が、重い。

proxyの出力をそのままブラウザに喰わせられることでは？＞XML

実際には XSLT で サーバ側で HTML か XHTML にしないとしおしおだが。

＞166
CSS for XMLって使えないの？

方向性としてはXMLということで次は何を決めればいいの？

>>168
suject.txt & dat の DTD/XML Scheme/Relax Scheme

どういうリクエストをだせば、どういう応答がかえってくるのか、ってヤツでは？

>>167
XML のまま食わすとブラウザを結構選ぶような

HTTPリクエストのAccept見たいに
accept: text/xml; text/cvs
とかして、現在鯖が対応しているのを返すというのはどうだろう。

>>172
そんなならURL自体を変えたほうがいい。

>>172
いいかも。あと、圧縮形式とか。
proxyの能力を見るコマンドを独立して作りたいね。

>>164
重い・でかいというデメリットに比べて
1-4のメリットは取るに足らないもののような。

不統一な各種datフォーマットをどれかに統一する
程度が現実的だと思うが｡

>>175
加工が楽ってのもメリットだな。
後は何となくかっこいい（ｗ

じゃあこんな感じ？

板一覧
<?xml version="1.0"?>
<boardlist>
　<board>
　　<server>pc.2ch.net</server>
　　<path>tech</path>
　　<board-id>pc.2ch.net/tech</board-id>
　　<boardname>プログラム技術</boardname>
　</board>
　<board>
　　<server>pc.2ch.net</server>
　　<path>unix</path>
　　<board-id>pc.2ch.net/unix</board-id>
　　<boardname>UNIX</boardname>
　</board>
</boardlist>

スレ一覧
<?xml version="1.0"?>
<threadlist>
　<board-id>pc.2ch.net/tech</board-id>
　<thread>
　　<thread-id>1011719933</thread-id>
　　<threadtitle>gikozilla</threadtitle>
　</thread>
　<thread>
　　<thread-id>1011659329</thread-id>
　　<threadtitle>VC＋＋よくわからん</threadtitle>
　</thread>
</threadlist>

gzipがよく効きそうなデータだな‥‥
そうそう、XMLなら、データベースに直接吐かせることもできるぞ。

>>178
それはcsvでも（略

でもって、スレ。
<?xml version="1.0"?>
<messagelist>
　<board-id>pc.2ch.net/tech</board-id>
　<thread-id>1011719933</thread-id>
　<threadtitle>gikozilla</threadtitle>
　<message>
　　<message-id>1</message-id>
　　<author>デフォルトの名無しさん</author>
　　<email></email>
　　<body>monazillaとは独立に２ちゃんねるに関連するプログラムを作るプロジェクト。</body>
　</mesasge>
　<message>
　　<message-id>2</message-id>
　　<author>デフォルトの名無しさん</author>
　　<email>sage</email>
　　<body>まず、gikozillaのミッションを定義しなければならない。</body>
　</mesasge>
<messagelist>

……重いような。やっぱCVSにしない？(弱

>>180 ×CVS ○CSV

やっぱCSVか

両方サポートしようぜ！とか言ってみるテスト

CSVだと一番最初に厳格にフォーマットを決めないといけない。
XMLなら２ちゃんねる側に仕様変更が生じてもある程度対応できそうだ。

まずないだろうけど。

>>183
作る人がいればサポートされるだろうね

age

ごめん。やっぱ撤回。
outputはひとつのがいいね。CSV支持。

>>184
確かにそれはそうだ

とりあえず現状での対応はCSVのみにして、
将来的には他のフォーマットもサポートできるような仕組みにするのはどうか。

フォーマットごとにURLを変えるのもアリかもしれないけど、
それでも窓口はひとつにしてリダイレクトで渡すほうがいい。

＞172の言うとおり、
acceptをきちんと取り扱えばOKじゃないのか？

>>189
同意。
最低限CSVサポートってことでよろしいかと。
XMLしか吐かない、となるとちと困る場合もあるし。

CSVで吐くならDATのデリミタをコンマに変換した形式になるのかな。

本文中のコンマはどのようにエスケープするのでしょうか？

基本的にXMLで吐くようにしておいて、CSVしか理解しないクライアントにはXSLTで
そのXMLをCSVに変換(超簡単)して返す方が賢いと思う。

Gikogate 1.0 Core Specification draft-draft

protocol
support charset
server requirements
client requirements

HTTPのラッパーにするか、
完全に独自のプロトコルにするのかという点も考えるべきだ。

個人的には前者だな。

>>194
重い（重くなる）んじゃないの？

今は分散を前提に速度より柔軟性をとるもんですよ。いや煽りじゃなくてマジで。
CSVなんて硬直したフォーマットを根底に持たないほうが絶対いいって。

オープンソースで、多数の人が使用するということを考える（一応）と、
転送量、鯖の容量などは考えていったほうがいいんでは？
（XMLをサポートというのは同意だけど、標準でXMLはどうかと思う）

XMLサポートを入れた場合、PDA以外のクライアントはどうせ、XMLでデータ
を持っていくと思うんだよね。あるいは、XMLでデータを持っていくほうが楽だ
と感じられる程度の技術を持った人間の作成したクライアントがシェアを得る
だろう、と言ってもいいかな。

だとすると、CSVをXMLに変換して返すというサポートの仕方は却ってオーバー
ヘッドになると思うんだな…。

クライアントの作りやすさを考えると XML だな。
msxml と IE コンポだけで何とかなる手軽さ。

>>200
んなこたーない。大体エンドユーザはXMLなんか知ったことか。何夢見てんだ?

202は文盲か？

>>201
gzipで圧縮すればXMLでもかなり転送量は減らせるはずだし、
IEにコンポ（プラグイン？）つければ終わりっつー手軽さがいいね

>>202
エンドユーザ？？？？

>>200
は日本語を勉強中の外国人の方です。ようこそ日本へ！

XMLを扱うのはクライアントで、
ユーザーが直接XMLを使うわけじゃないだろ。

めんどくせーから、両方対応必須ってことで。
次行こー。

206です。

>>202を煽るはずだったのに、>>200を煽ってしまった。
誠に申し訳ない。氏んでわびる。

じゃあ鯖に保存するキャッシュの形式について話しますか?
それともクライアントと鯖の通信方法?

順当に行くなら>>196
まじでCGIでやるのか？

>>210
クライアントと鯖はHTTPで桶でしょう。gzipもHTTP1.1でできますし。

別にCGIでもいいと思うな。あーそういえばmod_xsltなんてのもあるね。

>>213
mod_xsltとな。
ぐぐってこよう。

どういう独自ヘッダが必要になるかは他が決まってからかね。
キャッシュは DB 使えればレス単位で突っ込むのが簡単だが。

>>214
あ、スマン。
改造すれば今回のに使えるかも、たぶん無理だけど、
って程度のブツですわ。

>>609
どちらかといえばXV-5030

うわぁ、なんかめっちゃ誤爆…
首吊って(以下略

まずは実装

後の話だけど、Mozillaエンジンを是非使ってほしいな。

Mozillaで2ch専用ブラウザ
http://green.jbbs.net/computer/bbs/read.cgi?BBS=479&KEY=1003080409

ほんとにデータ形式をちゃんと決めなくて次逝っていいのか？
ココが一番重要だと思うんだが。

今のとこ、データ形式については、こんな感じかな。
最初CSVでも、初期なら途中からXMLにするのも、まぁ可能。
でも、XMLがカッコイイよね(笑)、monazillaと差別化できるし :-)

1△XML
2△CSV
3△XML->CSV
4×CSV->XML

とりあえず、csv,xml両方進めて行こう。サポートは任意で。
じゃ、内部形式だ。
csvデリミタは <> でいいのか？カンマは発言中に含まれるから ""での
エスケープが必要だが <> は絶対に現れないんだよな？

>>223
「<〜>」は、htmlのタグとかち合わなければ何を入れてもいいはず。
勿論「<>」も。

プロキシはSOAPのサーバにして専用のクライアントを作れば？

XMLは>>177,>>180 のままじゃないよね
板・スレにしろ属性分析が出来てないし

今日のよるにでもオレも考えてみるけど

クライアントサイドでP2Pやろうと思ってるんで、
スレのMD5値だけ貰えるコマンドきぼんぬ。

MD5より今はSHA1なんてどうか。

>>228
禿げしく妥当

>>224
オレ達の書きこみ「<>」は、read.cgiからは「＆ｌｔ；＆ｇｔ；」として得られる。
つまりhtmlだな。だから、発言中には絶対「<>」は含まれないんじゃねーの？

comma で separate されていなくても
comma separated value というかが問題だな。

>231
まったくだ。223がとても奇妙な発言に見えた。

>>232
カンマで区切ってエスケープ処理に苦しむ人生を選択したわけだ、キミは

やっぱりUNICODE流すの？

>>234
UNICODEでもカンマはカンマだろう。

>235
UTF-8ならな。UCS-2ならビットパターンは違う(8bitの 0 padding)。
ま、わかってるとおもうが。

>>236
UCS-2？

>237
聞きたいことは何ですか？

デリミタは半角『，』でいいんじゃないかな。既存のいろんなアプリで使えるし。
文章中の半角『，』は半角『￥，』でエスケープしとけばいいでしょ。
エスケープさせることに特にデメリットはなさそうだし…。

呼び方はともかく、<>の方が処理がめんどくさくなくていいよ、、、
もしくはタブ区切り

>>238
いや、それを言うなら UCS-2 ではなくて UTF-16 じゃないか、と。

タブ区切りに一票

なぜUCS-2の適当なコントロールコードをかっぱらってこない？

なんでUCSで送るねん。

厨房だらけ。

え？XMLなら、UNICODEとセットじゃなかったけ？

ちがう。
<?xml version="1.0" encoding="Shift_JIS"?>

確かにCES無指定時のデフォルトはUTF-8 or 16だが、
決してUCS-2ではない。

UTF-16で指定されるのは、UCS2のキャラクタではないの？

もうややこしいから、<>にしたら？

先は長そうだな

まぁ、楽をするために可変長区切りデータにするのなら、楽をするために'<>'を使うのが妥当かと。

いいからXMLにしとけよ。後でデータ項目とか属性増やす時どうすんだ？
後ろにずらずらくっつけてくのか？

2chの元データがCSVなんだから
そんなに無茶な変更するはずないだろ｡

エンコーディングはShift-Jisね。はいもう決まった。最終決定。

エンコーディングはEUCね。はいもう決まった。最終決定。

>>255
しんじていいのですか　ﾊｧﾊｧ

XML導入のときにうにコード化もするのかにゃ

>>256
ﾊｧﾊｧ　もうだめぽ

なんか予想通りの展開だな。
誰かがベースになるコードを一通り組んじゃわないと
先に進まないよ。

鯖くれ

エンコーディングはTRONコードね。はいもう決まった。
ホントの最終決定

>>260
鯖はやるが、回線は自分で調達しろよ

だれか、XMLで、ベースのコード書いてくれ。
そうすれば、CVSみたいにXMLに付いて来れる奴だけフィルタリングされる。

ベース。

int main(int argc,char* argv[]){
　return 0;
}

#!/usr/bin/perl

use XML::Parser;
use XML::Writer;
use strict;

ver 1.0　リリース

int main(int argc, char* argv[]){
　exit 0;
}

>>266
コンパイルエラーですが何か?

もろかぶったな。

＞268
どこの８？

要求仕様書をくれ。

XML正式採用
　↓
ローカルの過去ログファイルのサイズ数倍に肥大化
　↓
ユーザーに見放される
　↓
gikozillaプロジェクトポシャる
　↓
monazilla(ﾟдﾟ)ｳﾏｰ

XML正式採用
　↓
ProxyもClientも誰も書かない。
　↓
gikozilla (ﾟдﾟ)ﾅﾆｿﾚｰ

XMLだと XML database (DelphiだとTClientDataSetとか)にそのまま突っ込めて
扱い楽になったりする?

フォーマット: CSV
デリミタ: タブ文字(\t)
文字コード: Shift_JIS

以上に決定しました。反論不可

決定決定ってわめいてないでさっさとコード書けよ

んじゃ、次コマンド

GET板一覧
GETスレ一覧
GETスレ（範囲指定可能）
GETスレのSHA-1

他には？
個人的にはGET★さんの発言がホスィ

このスレはレガシーな厨房の宴の場か…

そういや squid 鯖を立てないで
専用サーバ/クライアントを作る理由ってなんだっけ？

>>277
人的リソースは限られているからね

レガシーってなんですか？
non-OO ってあたり？

及ばぬ鯉の滝登り

週末になるとさすがに、リア厨どもがなだれ込んでくるな。
まぁ、休みあけまでは不毛な議論繰り返して、また平日に
なったら再開というところかな。

いったいどこで中断したんだよ｡
継ぎ目がぜんぜん見えないぞ（うぇら

↑↑↑↑↑↑↑↑ 全員厨房　↑↑↑↑↑↑↑↑

---------------- <継ぎ目> ----------------

↓↓↓↓↓↓↓↓ 全員厨房　↓↓↓↓↓↓↓↓

ぐだぐだ。

while (!weekday) 不毛な議論();

unless(code) 不毛な議論

abort

一つだけわかったことがある。Monazillaの判断は正しかった。
MLは有能な人を取り逃す可能性はあるものの、厨房を黙らせるには効果的である。

厨房フィルタとしては、'sage'とか、閑散板でやるとかもある。

フォーマット: CSV
デリミタ: タブ文字(\t)
文字コード: Shift_JIS

>>274の言ってたこれで実装してますが何か？
ついでにhtml展開(エレメントの除去, ＆ｌｔ； ⇒ < 変換など)もやってます。

エレメントを除去したら何もなくなってしまいませんか。
除去するのは「タグ」でしょう。
http://www.ne.jp/asahi/minazuki/bakera/html/book/book3

>291
えらい！

>>282
gikozilla=レガシー指向(non-XML,non-OO,Cべたべた,厨房,親父,etc.)

という位置付けにして、もう一つプロジェクト立ち上げろよ

>>294
何を望んでるんだ？Webサービス化？

>何を望んでるんだ？
分裂に決まってんだろ｡
分裂こそが更なる進化と多様性をもたらすのだ｡

これ以降、XML主体の設計で薦めて行きたい方はこちらへどうぞ
http://choco.2ch.net/test/read.cgi/news7/1009233792/l50

>>決定決定ってわめいてないでさっさとコード書けよ

実装中心主義の典型的ﾚｶﾞｼｰ厨

We reject kings,presidents,and voting.
We believe in rough consensus and running code.

だめだこりゃ

Ruby >>>>>>>>>>>>>>>>>>> CSV
XMLにしろぼけ。

>300
てめーはRubyうーざーじゃねーだろ！
RDに決まってんじゃねーか。Raccで解析ああ楽ちん。

言語: Ruby
フォーマット: RD
文字コード: Shift_JIS

以上に決定しました。反論不可

C厨の夢の宴はここですか?

>302
邪魔すんなYO!

現在までの技術的成果

フォーマット: CSV
デリミタ: タブ文字(\t)
文字コード: Shift_JIS
言語: ANSI C

反論不可

>>160 さんを中心にすすめていくとうまく行くと思うYO!
struct が抜けてるのが気になるがな（ゲラ

>>160 さんを中心にすすめていくとうまく行くと思うYO!
スレ一覧なのに板…のが気になるがな（ゲラ

>>304
フォーマットがCSV(Camma Separated Values)なのに、デリミタが\tとは、これいかに？

フォーマット: TSV(Tab Separated Value)
デリミタ: タブ文字(\t)
文字コード: Shift_JIS
言語: ANSI C

はい決まった。もう決まった。

Valueが単数形なのにタブで区切るとはこれいかに?

フォーマット: TSV(Tab Separated Values)
デリミタ: タブ文字(\t)
文字コード: Shift_JIS
言語: ANSI C

ハイスキルを有するメンバー間の熱い議論の末、
ついにここまで磨き上げられました。

既にスレの1/3が失われた・・・。

javaでやりゃあラクだろうに・・・

javaもc#もrubyも不可。c厨の意地を見せてやる。

SJISとCSVの組み合わせは最悪。UTF-8のCSVなら納得。

>>314 は知ったか厨

タブ区切りにするならレス内のタブをエスケープする方法も決めとかないと。

>316
レス内にタブ文字は出てこないから大丈夫と思います。
>314
知ったか厨はお呼びでないんだYO!

そう? → ←これでタブ入ってるかな?

>>317
やっぱタブ入るみたい。

いっそのことNull Separate Valuesにしてみては。

ヌル文字すら入ることがあるぞ。
よって絶対に入らないことを基準に区切り文字を選びたいなら
それこそ <> くらいしかない

記事中の \t なんてどうせホワイトスペースにしか見えないんだから
スペースに変換しちゃえばいいのよん。 よってタブ区切りでｳｯﾎﾞｰ

専用ブラでポップアップしてるとちゃんとタブに見える場合もあります。
勝手にスペースに変換されるとインデントメタメタになるので困ります。
等幅モードがある苺やmegaBBSはOut of 眼中ですか。

>>318
NNならタブに見えるんじゃなかったっけ？

じゃあ<>で区切ることにしよう
ってこれなんて読むんだ？→<>

ひしがた

ダイヤモンド

いや、垂直タブ文字で区切る事にしよう。

１リクエスト１項目で取得。これ最強。




全部入るから <> 区切りにしよう。

データ形式: DSV(Diamond Separated Values)
デリミタ: <> (0x3c,0x3e)

>310
ﾜﾗﾀ

ここでXML, XMLって言ってるやつ
サーバリソースもちったぁ考えろよ
分散つったってサーバ引き受け先が
そんなにみつかるかどうかわからんのだしな

なんかとりあえず、プロトでも作って出したほうが早いかな

ブラウザ用のAPI決めれ
いいから早く

>>332
XML
XML

gikozillaを真面目に考えている人は、休みあけまでお待ちください。
土日厨があふれていますので。
それともいったん潜る？

とりあえず、週明けにはいくつかの実装が出てくんじゃね？
オレ？ オレも実装してるところ。クライアント付きだよ。お得だね！

実装方法に合わせてパフォーマンスの高いフォーマットで返したら？
もうテキストとしての可読性なんてステステ。
C厨は >>160 だな。Java厨はどうせcsvでもらってもxmlでもらっても
なんか扱いやすいクラス作ってそこに突っ込むんだろ？
なら最初からそのオブジェクトをシリアライズして転送してもらえよ。
もらう方は楽チン。サーバ書く奴らはがんばってくださいと。

>ヌル文字すら入ることがあるぞ。
ヌル文字入ったら、Cで扱う時困らない？
だから、ヌル文字はスペースか何かに変換して、NSVがいいと思う。

>>339
>Cで扱う時困らない？
一般的な感覚は逆だとおもうけどな。\0区切りはC厨あるいはジジイが良く使う手段だと思われ。
ネットワークからオクテット列を受信するAPIは\0に影響を受けるようには作らないからね。

>>340
舌足らずｽﾏｿ。
そこは、名前・メール・本文等の中のヌル文字を放っておいたら、
Cの文字列処理関数に渡す時困らない？ という意味。

>>341
だから前もってヌルは変換してしまえってことでは

まだ区切り文字で揉めているのか…
こんなところに下請けに出したら学校の宿題レベルでも1年かかりそうだな。

そうだな、区切り文字論争は不毛だ。
ここは、順当に固定長文字列にしとこう。

名前 32 bytes
メールアドレス 32 bytes
日付 YYMMDDHHMISS 12 bytes
本文 512 bytes

でいいだろ。

>>344
「初めてのプログラミング」という本を読んで出直してこい。

氷魚様の考え出した方式がたぶん世界最先端だと思う。
文字列の頭にその長さを置いとくの。
例えば"hio-sama"なら
08 00 68 69 6f 2d 73 61 6d 61
ってやるの。

つか、クライアントをＣで書く人なんているの？現状でもほとんどがDelphiなんでしょ？

>>347
monazilla系からのアクセスは拒否するんじゃなかったっけ？

>>348
そんなせこいことgikozillaがするわけないじゃん。
gikozillaはmonazillaに対してもオープンだよ。
monazillaがgikozillaフォーマットに対応するかどうかは知らんがな。

クライアント向けのAPIはSOAPベースですか？

>>350
SOAPにしたら結局XMLに戻るような(笑)

俺はXMLでもいいと思うが、実装する人がやりやすいのなら
スペシャルキャラクタによるデリミタでいいんでないかね。
クライアント側ライブラリももし作ればそこで中間フォーマットは吸収できるんでないか。

スペシャルキャラクタはNULで、元に含まれてしまっていたNULは他の文字に置き換えてしまう
のが楽でいいと思うが、元のデータの完全性を維持したいならエスケープ文字方式かね。
まあNULは置き換えてしまっていいんじゃないかと思う。

フォーマットの硬直性は、NUL区切りでもらうにしても、リクエストのときに
フィールド名を並べてリクエストすると、その順にNUL区切りで出してきてもらうようにすれば
互換性をとりながら使えていいんでない?

ケチるならフィールド名は1文字とかでもいいし。あんまり美しくないけど(笑)

ときどきNULが大量に入ってるdatもある

なんだってさしたる必然性もないのに
独自フォーマットにこだわるかね｡
お前らセンスなさ杉｡

>353
無能

>>353
必然性はあるだろ？ 近い将来 read.cgi経由でのhtml取得しかできなくなると
クライアントそれぞれでみんな一所懸命にparseしないといけないし、転送量も増加する。
それがかったるいからマンパワーを集中してサーバサイドで解決しようってこった。

ところで、書いたコードはどうすれりゃいいの？
だれかコードをアップロードできるサイト適当に立ち上げてくれんか？
他力本願寺ですまんがな。

PNGみたいにチャンクにすればいいじゃん。
後からいくらでも項目追加可能。理解できないチャンクは無視すればいい。

>355
sourceforge.net

>>355
それは共通化の必然性であって独自化の必然性ではないだろ｡
独自化の必然性がないなら今あるものにあわせりゃいいじゃん｡
たとえばム板のフォーマットそのまま使ってどんな不都合が出る?
# もちろん足りない項目があるけど単に追加していけばいいだけの話

つーかその主張は>>12で出てるだろ｡おんなじこと何度も書くなよ｡

XMLのメリットは2chクローン､ツリー型なんかの２ｃｈ以外の掲示板を
サポートするのでなもない限りまるでなし｡
XML推進派はまずそっちの可能性を検討したら｡

>ところで、書いたコードはどうすれりゃいいの？
とりあえずここ使えばいいかも｡
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/lounge/index.html

>>356
ｱﾌｫは独自フォーマット乱立してなさいってこった

某銀行のシステムは電文フォーマットだけで仕様書600枚以上あったな。
あれじゃ誰も管理できないだろ。

>353
なんだそういう意味ね。てっきりXMLでやれ派かと思った。
でもブレーンストーミングもしつつ、骨惜しみしないで各自で実装
ってのがいいと思うが。

>>358 = >>175
なるほどな。言われてみりゃその通りだ。必然性はないな。すまん。
>>162 も同じようなこと言ってるな。
とりあえず、手に入らなくなってしまった形式subject.txtとdatを
手に入れられれば良いということだな。

まぁ、当面は好きなことやってこうや。>>12 もプロファイル分けとか言ってるしな。
俺は一番マイナーそうな >>160 方式で実装を進めているよ。
メジャーな subject.txt & dat フォーマットはもう誰か書いてるんだろう？

おい聞いてくれよ！
今、subback.htmlを解析していたんだけど、なんか以前と形式が変わってるんだよ。
なんか base href とか使ってサイズを小さくしているみたいだ。
今は、subback.htmlとsubject.txtってほとんど違いないぞ。

まとまりのなさがすばらしい。
どこでどうまとめるのかがたのしみだ。うふふ。

そういうプログラムがあったとしてさぁ、バブル崩壊直前にそのプログラムは全部売れって指令を出したわけ？

>>361きっと骨惜しみの意味を勘違いしてる｡

みなさん、難しい方向から攻めていってますけど…。

2ch運営側がmonazillaを囲い込んでdatの使いまわしに
規制をかけようとしていますが、これに対抗する方法は
単純に

「通常のブラウザと同様の、read.cgiの出力とのやりとりで
同様の使いまわしを可能にする」
というやり方が一番簡単じゃないかしら？

datベースのmonazillaツールはread.cgiの出力を貰うよりも、
差分だけを貰ってくる分だけ無駄がなく速いですが、
これと同じことを通常のread.cgi出力に対して行うことは可能
ですよね？

例えば、このスレをレス300まで読み込んでログを保存している
gikozillaクライアントで、この↓
http://pc.2ch.net/test/read.cgi/tech/1011719933/
URLをリクエストすると、gikozillaクライアントがログの最終レス番と
比較して、自動的に
http://pc.2ch.net/test/read.cgi/tech/1011719933/301-
に読み替えてHTTPリクエストして、得られたデータをログに追加して
いくだけ。

あのね、（以下略
帰っていいよ

おーい平日だぞ。さっさと早く作れよ！

367と似たよなこと考えている人がmonazillaに。
http://pc.2ch.net/test/read.cgi/tech/1005282763/871

俺かよ。早！

なんか召還もされてるし…
でも、Gikozilla とはちょっと違う気が

gikozillaのサブプロジェクトとして、gikoクライアント設計すれ。

単独ではそのアイディア通りの動作を、gikozillaサーバが
提供される場合はそのクライアントとしてもログ取得など出来る
仕様にしてくれっちェ。

gikozillaのサーバが無ければ動作しないっていうクライアントは
ちょっと嫌なの。

今一番現実的なのは過去にも出てきたが、>>367見たいな奴か。
こういうことするなら、perlとかのが楽そうだな。

>>373

俺？俺？俺に言ってるの？
よーしパパ作っちゃうぞー
でも、叩かれソ
あとP2Pでやるなら検索も提供したいんだけど（さらに最低機能追加）、
俺の技術力がないから、効率的な方法がわからんのだよね…

>>375
ｶﾞﾝﾊﾞﾃ!

　　　　　　　／￣￣￣＼
　　　　　　/　/ヽ＿＿/ヽヽ
　　　　　 /　/ 　 o,,,,,,, oヽ |
　　　　　（　|二　 (_人_)　| ｎ
　　　 　　＼ヽ　　　　　 ノ.//
　　　　　　　/　　　　　丶／
　（＿ノ⌒ヽ|＼つヽ　x　 |　　　 ∧ ∧
　　　　　　　ヽ（酒） 　 ノ.　　　（=ﾟωﾟ）
　　　　　　 　i　|　U　| i　　 　　/ Ｙつ
　　　　　　　（_（＿＿ﾉ_） 　⊂（＿,,∪

>373
>gikozillaのサーバが無ければ動作しないっていうクライアントは
>ちょっと嫌なの。

単独で動くんなら、gikozillaプロ駆使なんていらんだろ。
直に2chにアクセスするのに比べて、遅くなることはあれ、速くなることはないんだから。

キャッシュを取ってなおかつ鯖が軽ければ
速くならないこともない

>>377

ちょとかぶるけど、混雑時と、dat落ち直後のログ取得に
よいんではないか、と。

それと、完全にGikozilla代理サーバ頼みだと今度は
そのサーバへの負荷がかかり過ぎると思う。
だから、単独で取得できるスレッドは単独で何とか
するのがファーストステップか、と。

>378
確かに、
2chからは更新差分のみを取って、プロクシサーバのキャッシュとマージして返してやれば、
全部2chから取るより速くなる可能性はある。

でも、頻繁にリロードするスレの場合、プロクシサーバの2chへの更新問い合わせを
キックするのが自分なら、直接アクセスした方が速い。
しかも、プロクシサーバのキャッシュが最新だという保証がない。
（最新に保つテクノロジはあっても、それが正しく実装されているとは限らない）

ので、プロクシサーバが高速化につながる場面は極めて少ないと思われる。

>>380

高速化に繋がらなくても存在意義はあるからいいんじゃなかろか。
自分が見たいときにそのスレはdat落ち直後でも、落ちる前に
だれかがGikozilla櫛通して閲覧していたら、そのログが残ってる。
それが取得できるだけでもメリット大有り。


…でも、普段の更新差分を2chサーバから直に受けてたら
Giko櫛はキャッシュを取る機会を与えられないのか…。困ったなぁ。

高速化よりトラフィックを増加させないことが命題だと思う。

留ｂｙさいじょうげんふぉ！
ｒびぃは小野ｐへんｇｐじゃくそ！
ｓｈじょんべん大すき

共通形式案
○デリミタは全て "," とする
○日本語はシフトJISとする
○不安な文字は全て%エンコードする 少なくとも単独の%は%25と表現する
　　注）%xx xxは１６進数でASCIIコードとエンコードする方式
　　区切りとしての","は%エンコードしてはいけない
　　データ中の","は%2Cに変換
○既定したレス数の後に","で他のデータを付け足す場合
　　,<TYPE>データ</>, のようにデータの種類を明示する事を奨励
　　TYPEの意味は公開する事

subject.txt形式案
○DAT_NO,タイトル,レス数%0d%0a

DAT_NO.dat形式案
　○１行目　　名前,メール,日付+時間,データ,スレッドタイトル%0d%0a
　○２行目　　名前,メール,日付+時間,データ%0d%0a
　○データ部の改行は<BR>で表現

なお、上の○DAT_NO,タイトル,レス数%0d%0a
　の %0d%0aは Win形式の行区切りの意味

仕様書らしく、BNFも付けといてくれよ。

Tiki に書いてみるテスト。
http://2ch.nekoruri.jp/tiki/?c=v&p=Gikozilla

>>879 + >>895
この二人は、是が非でも他人を自分よりも下であると思いたいらしい。
プログラマーってこんなｲﾀｲ人ばかりなの？

↑↑ ごめん誤爆です。↑↑
monazillaスレに書くつもりでした。

んな書き方だと叩かれるだけだから書かないで良し。

>>384
あれ? 2ch自体のフォーマットと同じでいくんじゃなかったの?
また独自形式の蒸し返し?

非独自にする必然性が無い以上
骨惜しみせずに好き勝手に
各自ばらばらに独自フォーマット作って
やりたいんだってさ。

>>291 だから2CHフォーマットっていっても沢山あるからまとめたんじゃないの？

>>391 2CHのフォーマットって言っても　鯖や過去ログによって
　　　　 <> だったり , だったりで共通ではないので　どれでも可よりは
　共通にした方がいいかな程度の意味で提案しました

　%エンコードとかは、一番簡単な安全なエンコードという意味で　勝手に追加したものですが
　他に良い案があれば撤回します

DATが見えなくなる以上、read.cgiベースでHTMLパースすることになるわけだから
2chのフォーマットがどうだろうと関係ないでしょ

>>395
・・・・・

>>12は何処行ったの?

＞395 既存のツール たとえばかちゅ〜しゃとかが　そのまま使えると便利と思いませんか？

正直2chの板ごとの差異なんて屁みたいなもんだから、わざわざ串用意して
フォーマット統一するほどのことじゃないよ。

これがJBBSとか互換系BBSも含めた話の場合になると、
・HTMLから記事をパースして共通DAT形式にする
・バラバラの書き込み用のCGIパラメータの差異を吸収する
・板一覧を共通形式にする
などなど存在意義はかなり大きいと思われ。今複数BBS対応してないブラウザも
急速に対応がすすむかもしれん。

いい加減はやく作れよ！カス揃いだな。

12は生きているよ。gikogate.cgi実装中。

>>399
ガイシュツ。

誰かServlet+Xalanでつくって〜。手伝うから。

>>402
無能

飽きたな。

>>405
飽きたよ。

飽きたな。

飽きたな。

は〜い、解散解散。
みんな元のスレに戻ってね

飽きたな。　

秋だな｡

12は放置ということで解散!

秋は松茸だな。

>>413
松茸は匂いだけだな。
秋はサンマだな。

お前ら！目を覚ませ！！！
まだ秋じゃねぇよ

もう冬か｡ﾏﾀｰﾘとﾈﾀｽﾚ｡ｿﾚﾓﾖｼ!

サンマはうまいな。

めちゃくちゃすげーアイデア思いついたよ!
だから､ちゃんと gikozilla 続けようよ!
そのアイデアとは ↓

目黒に逝ってサンマを喰う!

やっぱサンマはうまいな。

>>420
うまいな。

途中から､このスレ読んでる奴にgikozillaが何の事だか
さっぱり分からんだろうな｡gikozillaってのは､
おいしいサンマの食べ方について研究するプロジェクトのこと､
でいいんだよな？ >>12

そろそろサンマの季節だな。

でさ、>>405 〜 >>423 は何人で回してるの？
疲れない？　手伝おうか？

サンマは大根おろしだな。

で、ココ荒らしてるやつらって、gikozillaが完成すると何かまずいことがあるの？
単なる妬み？
単なる厨房？

こんなとこ荒らす意味がわからん。

平日になったら祭りがあると言っておきながら
何も起こらないので皆物足りないだけ

まともにプログラム書ける人が1-2人くらいしかいないのが原因だろう

なんだ、粘着が一人で荒らしてるだけか。(XMLを否定された奴？)
ご苦労だったが、つまらんのでもういいよ。
さらに誰も祭があるなんていってねーぞ。

つーわけで、>>12他みなさんがんばってください。

こいつマジでgikozilla書いてるらしいぞ。
パームでパーサー書くくらいならオレでもサーバー側で処理したいと思うし｡
というかPDAとか言ってるし､もしかして>>12なのか？
http://pc.2ch.net/test/read.cgi/prog/1010993649/l50

つか、gikozillaに参加してる、って香具師は、
１２くらいしか居ないみたいだがどうか？

>>431
正解

↓これなんかは、転送して加工してるんだよね?

http://i.chikara.biz/

お前らもっと>>12を持ち上げろよ。
落とすのは、ある程度完成したあとでもいいだろ？

>香具師
この板でこう言う単語を見るとは、ちょっとびっくり。

２ちゃん用語で「奴」と同義語だろ

>>436
おい。
ぁゃιぃわーるど用語だ

一応、こんな感じに作ってみたんですけど、
お気に召されるかどうか不安です。

こちらにソースを置いておきました。

http://koten.hypermart.net/

ローカルでは一応動きます。

##こういうcgiで良いんですよね。(汗)

>>428
1-2人ということわ-1人だね(藁

>>438
ありがとうございます。私も興味ありますのでぜひ参考にします。

>>438
その調子でがんばってくれ。
ほんとに週明けに成果が出てくるとわ、Gikozillaもなかなかスゲーな。

>>438
お. 早速置いてみました.
http://2ch.nekoruri.jp/nph-gate.cgi

http://2ch.nekoruri.jp/nph-gate.cgi/pc.2ch.net/test/read.cgi/tech/101179933/
で
read.cgi ver5.29 (02/01/17)<><>02/01/17)</b></font>投稿日：2001/04/12(木) 15:11<>そんな板orスレッドないです。<br><br><br>
<>そんな板orスレッドないです。

が返ってきました。なかなか順調そうです。
ここのスレは、ほんとは1011719933だけど、サーバに負荷をかけるので、ほどほどにね。
(これも、ＯＫです)

あ、ちょっと細かいけど、>>999形式のリンクは、
<a href=999 target=_blank>>>999</a>
よりも
<a href="999" target="_blank">>>999</a>
とかのほうが、いいんだっけ?

こちらはOKですけど、
http://2ch.nekoruri.jp/nph-gate.cgi/pc.2ch.net/test/read.cgi/tech/1011719933/l5

こちらは、何も帰ってきません。
http://2ch.nekoruri.jp/nph-gate.cgi/pc.2ch.net/test/read.cgi/tech/subback.html

>>445 俺は帰ってきたけど？
http://2ch.nekoruri.jp/nph-gate.cgi/pc.2ch.net/tech/subback.html

>>446
あ、まちがえた、はずかし、こちらでも、ちゃんと返ってきました。

これって subback.html じゃなくて subject.txt じゃない？

>>448
subback.htmlを取得して、subject.txt風に加工するcgiなのです。
詳しくは、
http://koten.hypermart.net/
を、熟読して下さい。

pu

まだかぁ〜？遅せぇーぞ！！

>>449
なるほど…つうかデータ形式が subject.txt なら subject.txt が良いと思うが。

>>452
わけわからん

テスト

＞454
それ、ロビー限定でわ。

gikozilla誕生は、Monazillaスレの144あたりからだね。

>>437
そうか。
「ヤツ」の変換違いから来たのかな。

「ヤシ」の変換違いだろ。
「ヤツ」→「ヤシ」の変化は変換違いではありえん。

すみません、遅くなりました。

>>442
akiさん、ありがとうございます。他の環境でも動く事が
わかってほっとしました。
これからもよろしくお願いします。

>皆様
ただいま、フィルタリング用のプロクシサーバを作ろうかと
思っています。

週明けくらいまでには何らかの返答が可能かと思います。
それまでお待ち頂けましたら幸いです。

よろしくお願いします。

平日は上げ

あ、下げた。

おいおい、話を進めすぎると>>12が登場しづらくなるぞ。

確実に飽きたな。

わたしも置いてみて動作を確認してみました。
最初ソースそのまま設置して動作させようとしたんですが、ぜんぜん動かなくてあせりました。
わたしの場合は一部ソースを修正しないと動いてくれませんでした。
ちなみに修正した個所は、「print "HTTP/1.0 200 OK$LE";」の部分をコメントアウトしました。
apacheのバージョンとかにもよるのかな。

>>464
CGIのファイル名はnph-gate.cgiになってる？
nph-をつけなかった場合は確かにHTTP〜は必要ないけど。

あ、そうか。NPHスクリプトか！
確かにそうです。適当にtest.cgiとかにしてしまいました。
私が悪かったです。ごめんなさい。>>438 >>465

私はスレッドファイルのキャッシュ機能を追加してみようと思います。
subback.htmlのタイトル横のカッコ内のレス数は常に正しいのかな・・・。

>>466
>subback.htmlのタイトル横のカッコ内のレス数は常に正しいのかな・・・。

透明あぼ〜ん1個にレス1個とかなら、表面上は、変化が無いように見えてしまったり

キャッシングするにあたって透明あぼーんの扱いが難しいよね。
確か透明あぼーんするとレス番号が詰まっちゃうんだよね？

>>468
前回取得レスの最後の1個だけ、余分に取って、同一性を比較する
というのを考えているけど、もっと良いのを思案中。

>>469
前後20個くらいのスレを比較して、順序に変化が無いなら、変化無しと判断する
あたりで、妥協するしか無いのかな?
で、レス数が変化したときに、>>469の方法で、確認するとか。

飽きたっぽい。

秋田っぽい。
やっぱりきりたんぽ鍋だな。

きりたんぽ鍋はうまいな。

うまいな。

ageておくか…

揚げもうまいな。

一日中、ネタ以外のレスなしかよっ！
これは間違いなく飽きたらしいな。

>>477
そんなことはない。みんなまじめに考えている。僕の提案はこうだ。
大小20個くらいのサンマを比較して、大きさに違いが無いなら、サンマうまいと判断する
あたりで、妥協するしか無いのかな?
で、レス数が変化したときに、>>472の方法で、きりたんぽ鍋にするとか。

ラーメン食いに行ってきます。

wgetで、ちゃんと返って来ます。クライアントは、これ使おうかな?

wget -O test.dat http://2ch.nekoruri.jp/nph-gate.cgi/pc.2ch.net/test/read.cgi/tech/1011719933/l5

ラーメンだったら、とんこつだな。

横槍が多すぎるんで、続きの議論はMLでやります。
[email protected]（ｗ

　|￣￣￣￣￣￣￣￣￣￣|
　|　　>>482おいおい♪　 .|
　|＿＿＿＿＿＿＿＿＿＿|
　 　　　 ∧∧ ||
　 　　　(*ﾟ∀ﾟ)||
　 　　　/　 づΦ

よーしパパgikozilla.orgとっちゃうぞー(w

そういえばread.cgiって昼と夜とでは挙動が違いますよね。
それによって出力されるHTMLも微妙に違うと思われます。
1度に100レスしか取れないのは分割して取得すればいいとして、
「>>数字」の部分のリンクが夜では外れてるような気がします。

お久しぶりです。
プロクシサーバを作ろうかと思ったんですが、
キャッシュをどのように処理するのか等、個人では決めかねる事も
ありましたので、サービスサーバを作成しました。

もちろん、様々なスクリプト言語およびC言語でサービスを提供する事が
できるかと思います。
ローカルでは一応動いています。

遊んで頂けましたら幸いです。
#CYGWINでは動作が何かぎこちないのですが、
#何かご存知の方がいらっしゃいましたら御教授ください。

端末ソフトなんだけどね。
今、迷ってるのは、ブラウザ回りをどうするかなんだよね。
IEコンポをオープンソースうんぬんで使うのは、あれだし、他OSに移植しにくいし。
かといって、ゲッコ〜回りは、資料少ないし、、、
とりあえず、使用ブラウザにHTMLを送るってのを考えてるけど、う〜ん。

グダグダ言わずに作れよ

>487
MFCで作ろうと思ってたのですが・・・駄目ですか？(^^;
IEコンポーネントは使わないつもりですが。

IEコンポーネントを使わずに、既存のＡＡ資産を活かす方法ってある？
俺も、できるならIEコンポーネントは使いたくないんだけど・・・・・・

>>485
たしかテレホ時間は、全部読めなかったはずなのに、今、読めてます。
ソース読もうと思ったのに、う〜ん。

>>488
たしかにねぇ、いちど始めれば、止まらないのかもねぇ。
>>489
なんでもいいから作れば、そこそこの資産になると思いますよ。
>>490
このあたりに詳しくないのですけど、関連スレとかあったら教えて下さい。
それに、資産と言っても、厨房板でAA作るようになってから、たかだか2年くらいなので、
かつてpc-9801から、AT出家者が続出したように、あっさり変わるかもしれないし。

>>490
あ、書き忘れた、いちおうモジラで、問題無く表示されてるような気がするので、
このへんが、なんか、しっくり来ないのですね。

あと、某G社とかへの対策も、頭に残ってたりするし。

>>492
現状、IE前提でAA作ってる人が多いわけで、それは多分今後も変わらないと
思うわけで・・・・・・って、モジラでもズレないの？
IEコンポ以外だとズレるのかと思ってた。

>>495
モナ板トップでズレなければ、OKらしいです。
モジラでも、フォントを12PのMSPゴシックにすれば、そんなにずれてないように感じます。
それにIE5.5以上では、フォントを設定しないと、まともに見れないようですしね。
なので、IEコンポの必然性って、よくわからないのです。

あ、モナ板へのリンク忘れた。
モジラでは、ほんの少しズレるのですけど、IEだと、全然ズレないのかなぁ?
ウイルスとか恐いので、IE使う勇気無いです。
http://choco.2ch.net/mona/

結論、勝手にちまちま仕様変更をする、MSKK&IEを標準にするより、モジラで幸せになりましょう。

う〜ん、プレゼンスとか関連ログ読みにハマってしまって、開発時間が全然無いし(大汗)

>>498
モジラは仕様変更が無いんですか,,

つか、MSKKは営業部門だけみたいな存在だから、
仕様変更には殆ど関与しないはず‥‥

>>501
あ、そっか、今は完全に営業所でしたねぇ、しまった。

>>500
春からの正式なやつでは、そこそこ固定ということになってます。
日本の開発者が増えて、日本語フォントをいぢる権限を持つことができれば、
いろいろ可能なことが増えるんだと思います。

>>503
あ、そうか、Mozilla 1.0 出るんですね。
なんだか楽しみ

ほほぉ〜２日間も放置ですか。飽きたみたいだ。

こんなことやっています。

program Gdat2html;
//Gdat2html.exe v0.1 2002/2/9:datファイルをhtmlファイルに変換
//実行例:Gdat2html ファイル名.dat
//作り方:新規で開いて、フォームを消して、表示->ユニットの表示でdprを開く
//作成環境:Delphi6Personal/Win98
//これの扱いはGPLです
uses Classes,SysUtils;

続き、をっと、こんなことやってる場合じゃないか。

uses Classes,SysUtils; //芸人の所属プロ

{$R *.res} //裏方

var //登場人物[劇中名:芸名]
i:Integer; //ループ変数
sp,ep:Integer; //SP=スタートポインタ、EP=エンドポインタ
SL1:TStringList; //datデータ文字列リスト
SL2:TstringList; //htmlデータ文字列リスト
name,mail,date,body,title:string;//名前、メアド、日付、本文、タイトル

アップ(ってなんですか)しときました。ソースのみです。

http://2ch.nekoruri.jp/tiki/?c=v&p=GDatToHTML

終わったのか… 寂しいな。

>>509
少なくとも、私は、残っていたりするのだ(笑)

飽きたね

>>511
読んで、ブラウザに表示するとこまでは、できたのだった。
これで、2ch禁止の会社から、携帯サイト使わずに、プロキシ経由で2chが読めるのだ。
わはは

＞あほセブン
一人でやってろ

要望。
datの圧縮差分取得がしたい。圧縮はgzipじゃなくてdeflateでいいや。
gzipだとヘッダをカットするのが面倒だから。がんばれ、seven。
実はオレもこっそり実装してる。

>>514
圧縮差分てのは、鯖とか串の問題なので、えらいひとにまかせます :-)

>>514
あ、いいわすれた。
datの直接取得は、gikozillaの趣旨(ってなんですか)に反するので、興味ないです。

>>516
いや、dat(フォーマット)が欲しいというのはクライアントとしての要望。
君が裏でがんばってHTMLの必要記事番号だけをまとめてdat化して圧縮。
リクエストを出すクライアントは、そんなことしったこっちゃない。
だから、dat圧縮差分取得させれ。

>>517
あ、なら、>>515です。
CGI串使える鯖のお友達いないしね。

えっと、端末ソフトですけど、とりあえず、串と直接と切りかえられるようにして、
ソースを整形(これがめんどいんだよね)して、どこかにupすることにします。

>>519
何で書いてんの？ Cで書いてるんだったら是非 参考にしたい。
HTML -> dat 処理部とかね。Perlだったら、テキスト処理が Cとは
段違いに平易に書いてあるだろうから…。まぁ、がんばってくれよ。

>>520
ええと、HTML->datは、いまんとこ>>438のperlで、実装は、>>442ね。
私はDelphiで端末書いてて、いまんとこ>>508だけです。

半角で流れている画像その他を、p2pで共有するソフトきぼん。
gikozillaの大きな目玉ってことで。

>>522
作ってみてね　:-)

さて、外部プログラム起動のプロシージャを書いときます。
//外部プログラム実行
procedure TForm1.Exec(CmdLine:String);
Var
SI :TStartupInfo;
PI :TProcessInformation;
begin
GetStartupInfo(SI);
SI.wShowWindow := SW_MINIMIZE; //窓最小化で実行
If Not CreateProcess(nil, Pchar(CmdLine), nil, nil,False,
CREATE_DEFAULT_ERROR_MODE,nil, nil, SI, PI) Then
Raise Exception.Create('Exec Error ' + IntToStr(GetLastError));
While WaitForSingleObject(PI.hProcess, 0) = WAIT_TIMEOUT Do
Application.ProcessMessages;
end;

>>522
プログラム板なんだから自分で作らなきゃ・・・って言おうと思ったけど
なんかめんどくさそう（ｗ

なんか、オイスター作戦のほうに動きが出てきたけど、
1 有料ツールが売れなくなって2chが潰れても困る。
2　仕様が固まるまで、怠けられる理由ができた。
という理由ができたので、しばらく静観してます。
Gikogateは、対応できるようにしておいて、端末から直接htmlを取得する
方向で考えています。
書きこみをブラウザからやるかどうか、迷ってる。
できるだけ外部コンポを使わないようにすると、けっこうしょぼいものしかできなさそう。
まぁ、それでも汎用性がgikozillaのコンセプトなんだよね?

>2　仕様が固まるまで、怠けられる理由ができた。
なんの仕様？

>できるだけ外部コンポを使わないようにすると、けっこうしょぼいものしかできなさそう。
ここは悩むね、Indyぐらいなら使ってよさそうだけど。

>>526
仕様とは、オイスター作戦の仕様です。
httpからのgetは、wget.exeでやることにしたんだけど、putをどうするかとか。
putだけindyでやろうかな(笑)、socketめんどいし。
ログ表示は、WindowsはTRichEditで、LinuxはTMemoにしようかと思ったけど、しょぼい。
タブの実行時生成も不安定になりそうだし。

>>527
こいつがGETもPUTもできてオススメ
  http://curl.haxx.se/download.html

ありゃ。typoスマソ

age

sage

>>528
cURLですか。面白そうだけど、なんか、めんどくさそうですね。

漏れもこっそり実装してたりする。
けど、2ch側の仕様変更についていくのが面倒になってきたよ。

がんばれ
保全age

なあ
俺が掲示板専用サーバー作ろうか？
HTTPで全部やり取りするのにも全部飽きた気がしないか？

一部有料化の波が押し寄せてきているこの2ちゃんでこのスレの傾向はいいと思います。
535さんがんばってください。

>>535
技術的には、にちゃんねるよりグレートな掲示板システムなんて
簡単に作れるって人は多いと思う。
にちゃんねるのデータ保持形式とかクソだしな。

でも、掲示板にとって一番必要なのは「書き込み」なんだよ。
よーするにヒトだな。今から専用システムを組んだとして
人が集まるのかはなはだ疑問だ。

だから、gikogateでは にちゃんねるのラッパとして実装し
インターフェイスを規定することが目標となった。
そしてそのgikozillaAPIに準拠したクライアントの開発も
進めていこうということになった。

あれから、2ヵ月経って熱が冷めた感もあるが、
まだまだ諦めてないやつらもいるはずだよな。sevenとか。

だから、>>535 がにちゃんねるのインターフェイスとして
専用プロトコルを定義してくれるんならとってもありがたい。
が、にちゃんねるの膨大な資産が利用できない掲示板システムはやめてね。

>>537
最近は巨大な掲示板システムが乱発しているせいか、
2ch自体有益な情報が減りつつある気がする。
少なくても､ユーザーは減少しているはずだし。

2chを作ったヒロユキ氏の発想と行動力はすごいと思うけど、
もう2chは時代遅れになりつつあると思う。

2chから多くを学んだ新しいスタイルのコミュニティーツールを作ることは
すごく興味がある。
もちろん2chは2chとして残ればいいと思うし。

もし賛同者がいればスレを立てて欲しい。

>>538
スレ立てることねーって。ここでやりなよ。
gikozillaのAPIだっていまだに規定されてないんだからさ。
君は君で専用プロトコルを定義して使い易い掲示板システムを考えてみろよ。
他の人間が、その掲示板システムでにちゃんねるのデータを
透過的に扱えるようなインターフェイスを書いたり、
日次バッチインポートとか書くかもしれないしな。

>ここでやりなよ。
すれ違いだという意見が増えたらすぐ消えますんで。
そうさせてもらいます。

掲示板の目標は
円滑な情報交換ができるような機能を持った専用のコミュニケーションツールです。

現状を報告すると、実際に少しづつコーディングを始めた段階です。
これはプロトタイプとして作っていますので、
完成しだい負荷を計測して、０から書き直す予定です。
言語はJavaです。
クライアントは最初JAVAで書き、余裕があればVCで実装するかもしれません。

サーバーはDDNSを利用する事で、ADSLを経由した家のPCで動かそうと思っています。
サーバーの為にlibrettoのような小さいノートを購入しようかとも考えています。

HTTPでは実現できない機能として
新規メッセージ通知サービスを実装したいと思っているのですが、
書き込みやクライアントの数によっては無理そうです。
この辺のアドバイスをいただけたらうれしいです。
P2Pスレは最初からセキュリティー的に無理だと見切りをつけていたので
参加しませんでした。

どういう機能があれば円滑な議論などができるのか、
アイディアがあればお伝えください。
貪欲に吸収させていただきます。

>>540
それって結局君が否定するP2Pの形にならざる負えないと思うよ…

gikozillaがインターフェイスとしての道を選んだ理由のひとつに
「潤沢なストレージを用意できないから」ってのがあったよね？

リブレットでご自宅サーバ？ かなりストレージ面で無理があるよ。
そういった問題を解決していこうとすると、>>541 が言うように P2P にならざるを得ない。

とりあえずインターフェイス、まずは にちゃんねるに寄生する形で
gikozillaとしての実績を作ってみるってのはどうか。

>>541
新規メッセージ通知は出来ればつけたい機能ということで。
有料化して専用通知サーバーでも立てれば､簡単なんですがね。

どうしてJavaなんですか？単に538さんが慣れてるからですか？

>>544
JavaベースのブラウザもMonazillaにあったような

>>544
・LinuxでもWindowsでも動かせる
・C++よりも開発効率が高い(メモリリークが抑えられる）
・Javaは勉強中
・ruby,perlも考えたが保守がきつくなり、パフォーマンスも期待できない
という事で
JAVAです

>リブレットでご自宅サーバ？ かなりストレージ面で無理があるよ。
自分なりに計算したので、それを次回書きます。
というか､ストレージがどんな意味なのか教えてもらえるとうれしいのですが。

ちょっと家を出ないといけないので・・・・

ちなみにgikozillaはどこにサーバーを設置するんでしょうか？

>>538
>有料化して専用通知サーバーでも立てれば

カキコが発生するたびにクライアントに通知するサーバー？
P2Pのように各サーバントに委譲しないでやるの？それだとサーバに負荷かかりまくりでは？

もーいーや。
ひとりでかちゅ〜しゃもどきをつくるよ。
さよなら。

>>547
p2pの方に公開鍵暗号で・・・と言う発言をしたのは私なのですが、
通知だけp2p式にする事も視野にいれています。

何を通知するのかにも寄るのですが、
例えばスレッドごとに登録されたクライアントに通知する場合
トラフィックは減少しますが
サーバーリソースを食います。
もう一方の端的な例は、
どこかのスレッドに発言があるたびに
全クライアントに通知する方法です。
現在こちらの方法をとろうと思っています。

通知だけであればIMサービスよりはらくだと思っていますが。

２ｃｈの書き込みを観察してもらえばわかるのですが、
書き込みで処理が追いつかない事はとうてい無さそうです。
つまり、その書き込みに対する１クライアントに対しての通知は楽勝ですね。
クライアント数が増えてくると問題になります。
現状ではクライアントの数すら予想がつかないのですが・・・

掲示板のスレッドをIRCのチャンネルにみたてて、スレッド参加者毎に
グループを再編してやると、P2Pでもレスポンスは随分良くなる。
でも純粋なP2Pだと再編自体が結構やっかい。
やっぱサーバが欲しい。
あとサーバが有れば書き込み時間の保証ができるから、書き込み順
を維持できたり、不用な書き込みを連続でするクライアントを追い出せ
るってメリットもある。
サーバに掛かる負荷が未知数なのがアレだけど・・・・・・

期待age

っていうか、突っ込みどころが多すぎて…。

もう少しゆっくり考えてから作ったほうがいいよ。

552ってもしかしてオブジェクト指向スレで晒しageされてた奴かも。
だとしたら､口だけ野郎なので気にするべからず。

残念だが人違いだ。私はvojta作者です。

>>554
あやしい・・・
多いってなら、１０個くらいは突っ込めるんだろ？
どうせ､口だけ野郎は１つも突っ込めないと思うんだが。
そうやって「　」も逃げていったな（藁

「　」晒しメタage

つーかさ、みんなボケまくろうぜ！そいでもって、ツッコミまくろうぜ！
ボケとツッコミの繰り返しで何か生まれるかもしれないじゃん（ｗ

>>556
おまえが最初にやれ､クソボケ

なるほど、556が クソ「ボケ」で、557が「ツッコミ」だね。
では、次のボケのかたどうぞ！
↓

　∧ ∧∧ ∧ 　　／￣￣￣￣￣￣￣
　(ﾟДﾟ≡ﾟДﾟ)　＜　ど、どうﾎﾞｹろと？
　　 ./　　|　　　 　＼＿＿＿＿＿＿＿
　　（＿__/
　／

はい、次の方。
↓

∋oノハヽo∈　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
Σ( ；´�D｀)　＜ きゅうにボケろといわれてもこまるのれす、・・・
　　⊃　⊂　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　(___)__)　ﾋﾞｸｩｯ!

技術的な面は置いておいて、
機能面での要望などはありませんか？

datファイルを直接読んでいるんですけど
毎回全部ダウンロードするのは効率悪いので
差分のみをダウンロードしたいんです。

どうしたらいいのでしょうか？
（あぼ〜んされたときの話はとりあえず置いといて）

If-Modified-Since の使い方がよく分からないです。
いい解説サイトありますか？

別スレでききんしゃい

RFC読めよ
ていうかこのご時世、鯖に余計な負荷かけんなよ

>>566
If-Modified-Sinceは鯖負荷減らすためのものだべ?
毎回GETするのに比べて。

というわけで、2ch.dllを作りましょう

>>567
だから、そーゆー当たり前のことをやらずに >>563 みたいな低スキルな
コードで迷惑かけんな、って言ってんの

板移転に強い、理想的なログの持ち方について
現状、どのビューワの形式がいいですかね

>>570
過去ログ読むか、モナジラスレ行きな。
ここはな、モナジラ路線を否定しているスレだ。

>>571
つーか、いいものはパクる。 そういうのはいいんじゃないか？

>>572
パクリは良いけど、この板でのFAQはごめんだ。

FAQか？

>>570
えっと、XML最強なはずだけど、食い付きわるくて、現在は'<>'区切りっす。

で、クライアント作成はどうなったよ？ > seven

>>576
しょぼいのは、あるよ。
最初ブラウザ表示作ったけど、大きなログ読むと、かちゅと同じで表示が遅いので、
100ずつ表示させようとしてTMemo使ったら、色付かない。
TRichEditは素性わるいし、TEditorだと、GPLには似合わないし、、、ってな感じ。
で、チョコ鯖とかの仕様待ちということに(汗)。
あと、書きこみがめんどくさそうで、手をつけてない。
wgetみたいなwputとか、無いかなぁ?

>>577
えまのんや Jane Doeと同じ方法じゃだめなの？

>>577
がんばってんだな…。
サーバ書いてるやつらももうちっと成果発表して欲しいもんだ。

>>578
TWebBrowser使用は、IE依存になるので、パス。
1レスずつの表示は、1行レス多数になると、、、
wgetとか使ったりして、ブラウザとは別のアプリで標準ログを保存して、
これをブラウザで読むことで、比較的多数のcgiに対応可能にすることを画策中。
とりあえず、色が無くても良いような気が、だんだんしてきた。
でも、めんどくせ〜、だれか作ってくれ〜。

>>580
いや、えまのんや Jane Doe は TWebBrowserを使わずに
描画を実装してるんです。Jane Doeはソース公開なんで参考にされてみては？

>wgetとか使ったりして、ブラウザとは別のアプリで標準ログを保存して、
>これをブラウザで読むことで、比較的多数のcgiに対応可能にすることを画策中。

おお、詳細きぼんむ。

>>580
>wgetとか使ったりして、ブラウザとは別のアプリで標準ログを保存して、
>これをブラウザで読むことで、比較的多数のcgiに対応可能にすることを画策中。

monazillaにもそういうコンセプトの奴はあったような気が..
画期的なアプローチｷﾎﾞﾝﾇ

>>582
j2ch-cache
http://www.geocities.co.jp/SiliconValley-Cupertino/5226/

>>581
Jane Doeの利用者になることにしました。ありがとう。

ところでseven氏ってPigSleepとかのCGI作ってた人？

>>585
トンと心当たりありません。

>>582
monazillaは、基本的にdat読みですよね?
gikozillaは、基本的にhtml読みなんです。

HTML読みで一番困るのは「省略されました」ですね、

>>587
え？
read.cgiってこと？

>>586
なるほど（藁）
ま、某氏によろしく（藁）

よくわからないけど、感動した！傍観しますた！

>>589
あまりメジャーになる気は、ありません。

read.cgiがプレゼンテーション層の機能までも持ってしまっているのは
gikozillaにとって大きな障害だよな。生データを忠実に渡してくれれば
いいのに「省略されました」とかねー。
html読みでも、それなりに課題はあるってことだな。
monazilla加盟以外に生データにアクセスする手段ってないのか？
ほんっと、にちゃんねるの体制って糞だな。
sevenもっとがんばれよ。てゆーか、おまえがサーバ側も書いちゃえば？

数学に強い人、圧縮率lhaの10倍・可逆な圧縮規格を作りませんか？

自称、数学に強い人が、1/100圧縮を発表してましたが、なにか。

LHAはスライディング辞書とハフマンの組み合わせだろ
ハフマンは大変遅い。
スライディング辞書だけだと、スライディング辞書とハフマンの
８５％の圧縮率だけど展開は１０倍は早い。

>>587
そのソフトに関して言えば、2chのみDAT読みで、他は全部HTML読みだよ。

>>597
ふーん、そうなの。
って、ログとか読んでると、開発する時間がなくなるしぃ。
とりあえず、しょーもないソフト群を作って、誰かが、それより優れたのを作ってくれて、置きかえることを期待してみようかな。
コンポスタイルってことで。「省略されました」非対応(笑)。

省略されましたって何?
公開でread.cgiいじれてたころはそんな機能なかったと思うが。
bbs.cgiには昔からあるけど。

600ｹﾞﾄｰ

601

定期age

お前ら、もう終わりか？

ageとかないと。

>>603
一ヶ月近くｶｷｺ無いって事は、そういうことでしょ

いーや、sevenは諦めてないよな？
GW明けには進捗報告とかあるんだよな？ な？ な？

>>606
うげ
うげげげ
やらんといかんの?
一定の効果もあったようなので、もぅ、いいのかと(汗)

>>607
はやくコンポーネントの大枠を設計して インターフェイス公開汁！
漏れもコンポーネントのひとつやふたつ書いたるから。

>>608
大枠とか設計つーても

1各サイトからのhtml取得ソフト
2html2gikozilla形式DAT変換ソフト
3gikozilla形式DAT閲覧ソフト
4各サイトへの投稿ソフト
5ユーティリティー

ってくらいだけど。

それで上等♥

n

けっきょくどうなったの？

特に運営側がヤバイことしてないので、当面放置

ようするに終了ってことか。

&hearts

やはり、私がいないと駄目ですね...。

gikozilla.rb