★ INCM Plug-in開発掲示板 ★ TinyGrass Ver0.32a ［戻る］
[0226] 00/10/23 17:50 GAE(3nxWzOCXjo.): Re:225)Re: C: I:
>> 記事と同じフォルダにアイコンGIFを落として、I:にファイル名を書けば
>> タイトルビューにアイコン表示出来ます（表示→タイトルビュー→記事アイ
>意味は存じていたのですが、MBXからCMTに変換してINCMにデータが渡った時点で
>I:の行が消されてしまうので…。(^^;
CMTプラグインが古いと消えてしまいます。
>＃ でもgifですか…。例の問題があってヤだなぁ。
ちなみに画像を展開する処理などは全く組み込まれていなくて、
susieが必須です。
ちなみにアイコン表示すると猛烈に処理が重くなります。
実験的に付けた機能なので、一応確認できる程度です。
>> C:は文字色ですが、現在使われてないかも？
>こちらは書式が判らないのです。HTMLのような「#RGB/#RRGGBB/#RRRGGGBBB」で
>宜しいのでしょうか？
色は、S:の属性の次に RRGGBB 形式で記述します。
といっても、文字色ではなくアイコンの色になってしまいますが(汗)
[0225] 00/10/23 17:19 風葉(/Z7FKywOcl2): Re: C: I:
> I:はアイコンのファイル名です。
> 記事と同じフォルダにアイコンGIFを落として、I:にファイル名を書けば
> タイトルビューにアイコン表示出来ます（表示→タイトルビュー→記事アイ
意味は存じていたのですが、MBXからCMTに変換してINCMにデータが渡った時点で
I:の行が消されてしまうので…。(^^;
該当する画像ファイルをダウンロードしていないので、既にこの時点でファイル
チェックして弾いているのでしょうか。うぅむ。
次のリリースではアイコン対応させたいです。
＃ でもgifですか…。例の問題があってヤだなぁ。
> C:は文字色ですが、現在使われてないかも？
こちらは書式が判らないのです。HTMLのような「#RGB/#RRGGBB/#RRRGGGBBB」で
宜しいのでしょうか？
あと、訂正です。
> ・「番号」が数字で始まっていない
これは間違いでした。INCM掲示板2の過去ログ参照。
[0224] 00/10/23 07:03 一 五明(YMjHyfzdazU): Re:223)C:とI:
>確かに資料が乏しいのは否めないですね。実は私もI:とC:の使い方が判りません。(^^ゞ
I:はアイコンのファイル名です。
記事と同じフォルダにアイコンGIFを落として、I:にファイル名を書けば
タイトルビューにアイコン表示出来ます（表示→タイトルビュー→記事アイ
コンにチェック）
ただ今まで、アイコンのダウンロードに対応したプラグインが無かった
だけです(^^;
（CMTplusは対応してるみたいですが）
C:は文字色ですが、現在使われてないかも？
http://kt.sakura.ne.jp/~timeflow/M/
[0223] 00/10/22 23:41 風葉(/Z7FKywOcl2): Re: thread
> S:3176,3100 ....
確かにこの書式ですね。
結構陥りやすそうな事例として――
・参照している番号のメッセージがない
・end-of-lineがCRLFになっている
・「番号」が数字で始まっていない
・「,」と要素間に空白がある
・M:が「.」で終わっていない
などなどでしょうか。
因みに、拙作cm_Falcom.exeではメッセージナンバーを1000929144256と、かなりの桁の数
（実はY2K対応していないFalcom BBSの内部日時表現そのまま(笑)）を使用していますが、
CMTに変換すると201795090と値が変わりました。(^^;
＃ INCM内部での変数の値が溢れたようです。
> また、こうした開発の為の情報（incmのデータ構造など）は、どこかに解説させているのでしょうか？
確かに資料が乏しいのは否めないですね。実は私もI:とC:の使い方が判りません。(^^ゞ
＃ cmt_format.txtにも載っていませんし。
一度、GAEさんにメールにてお訊きしたのですが、ご多忙なようで…。
[0222] 00/10/22 23:26 風葉(/Z7FKywOcl2): Re: WinInet API
> httpsのポート番号って、何番でした？＞GAEさん
お呼びではないと思いますが(笑)、443番です。
＃ shttpは何番でしょう。:-)
> ざっと斜め読みしましたが、httpsに対応しているのかどうかは不明です（記述
> がありません）。私のイメージとしては、WININET.DLLの向こう側で対応してく
> れそうな気はするんですが……すくなくとも、ポート番号は指定しなければなら
> ないかもしれません。ポート番号のデフォルト指定がWININET.DLL側で行われて
> いるなら簡単なんですが……
ftp,gopher,http,httpsとSOCKSに対応しているみたいです。ポート指定しなければ其々の
デフォルトが適用されます。
httpとhttpsの違いは最前申し上げたようにフラグ一つの違いです。
「INTERNET_FLAG_SECURE」を立てればhttpsです。
＃ これをつけたままhttp接続するとエラーになります。暫くこれで悩みました。o(^^;
[0221] 00/10/22 13:02 たこぽん(ClFgljwGZwg): ツリー表示にするには
プラグインをつくってみてるのですが、記事は取得できるようになりました。
ただ、タイトルビューでツリー表示されなくて困っております。
001.cmt に、
S:3176,3100 ....
のように、親記事の番号を書くだけではうまくいかないのでしょうか？
教えてください。
よろしくお願いいたします。
また、こうした開発の為の情報（incmのデータ構造など）は、どこかに解説させているのでしょうか？
たこぽん＠練馬
[0220] 00/10/22 08:33 Buckeye(UnTUYw5MC2c): Re:217)Win32::Internet
風葉さんの211を見て、もしかして、標準配布のモジュールですむのなら、大き
な実行形式ファイルではなく、小さなスクリプトだけですむのかもって思って、
エクスプローラでperl\html以下のフォルダを順次眺めていって、昨日、ちょう
どみつけたところです＞Win32::Internet
スクリプト配布なら、今起きているページ違反から逃れられる代わり、
Perlをインストールしてもらう必要がありますね。Perlって何？って人も多
いので、できたら、実行形式ファイル「も」配布できるようにしたいですね。
ざっと斜め読みしましたが、httpsに対応しているのかどうかは不明です（記述
がありません）。私のイメージとしては、WININET.DLLの向こう側で対応してく
れそうな気はするんですが……すくなくとも、ポート番号は指定しなければなら
ないかもしれません。ポート番号のデフォルト指定がWININET.DLL側で行われて
いるなら簡単なんですが……
httpsのポート番号って、何番でした？＞GAEさん
httpsアクセスを調べていた最中に英語ドキュメントのどっかで見た記憶は
あるんだけど、見つからなくなってしまいました＞ポート番号
Best Regards,
Buckeye
[0219] 00/10/22 03:18 風葉(/Z7FKywOcl2): Re: WinInet.dll
> Win32::Internet - Access to WININET.DLL functions
なるほど確かに。
これでしたらWinInet好きの方は重宝しますね。
＃ 私は先の理由により使用しませんが。
利用しているモジュール内でWin32::APIの記述を見つけただけでしたので、全く存じませ
んでした。site/libもちゃんと覗いた憶えが…。(^^;
[0218] 00/10/22 03:13 ？？？(/Z7FKywOcl2): Re: WinInet.dll
> Win32::Internet - Access to WININET.DLL functions
[0217] 00/10/22 00:35 でぐ(MVbPwfyRCtk): Re:212)Re: cm_Plug-in.exe
> そうでなければ、https部分をWinInet APIにやらせてしまう方が「楽」だと思います。
> ＃ あ、でもPerlのみでWinInetを使おうとするとWin32::APIが必要になりますね…。
えーと、自分で使ったことがないため、使い方もわからなければ動作も確認していないので、こっそりと。
コマンドラインで「perldoc win32::internet」を叩いてみてください。
きっと、下の一文から始まるドキュメントが流れると思います。
Win32::Internet - Access to WININET.DLL functions
このモジュールはActivePerlインストール時についてくるようです。
http://degitian.portland.co.uk/index.xml
[0216] 00/10/22 00:08 風葉(/Z7FKywOcl2): Re:quest quantity
> この辺詳しく調べてないんですが、CGIをテストしていて、ある程度出力し
> てからPerlが実行時エラーで落ちたときに、出力内容は1バイトも送られて来
> ずにサーバーエラーが返ってきたことが有るので、CGI出力はバッファに溜まっ
> て行って、プロセスが正常終了すれば転送開始、異常終了なら破棄だと思っ
> てました。
まさにこの「バッファ」が大いに原因かも知れませんね。バッファサイズが大きければ
そのような症状の説明が簡単につきますし。
> 実際はCGIプロセスの終了待たずに転送開始することもあるんでしょうか？
これはあります。実際やっていました(笑)。
どのようなCGIかというと、CGI&Robotという代物です。(^^;
Robotの実況をCGIの出力として吐き出すものです。バッファリングをさせていないので
出力が処理が進むたびにちょびちょびと流れてきました。
ですが――
> （サーバーによるのかも）
これが正解だと思います。
MSNJournalプラグインはMSがアクセス対象なのでASPをリクエストしますが、レスポンス
にはContent-Lengthがついていました。
ご存知のように、プログラム出力のリソースでは処理が終わるまでサイズが判らないこと
が殆どですし、それを行うとしたら出力を全て溜めておいて計算してからストリームに流
すことになります。ヘッダが文字通り先頭にしか配置できませんからね(笑)。
こうしたタイプではhttpdが終了まで待機しているかは判断出来かねます。
この処理をhttpdが行っているのであれば、仰られたようにhttpdはリソースプログラムの
終了を待っていることになります。この場合は例によって.asp（＝IIS）なのでお手上げ
です。(^^;
[0215] 00/10/21 23:54 風葉(/Z7FKywOcl2): Re: cm_Plug-in.exe
> PDKによる実行形式化は、必要なperlスクリプトやモジュール、関連するDLLを、
> Perlの実行エンジンとまとめてexeに必要なヘッダをつけたもの、というイメー
> ジのようです。ファイル内をむりやりのぞいてもテキスト情報はほとんどないの
> で、perlスクリプトの部分は中間言語にコンパイルされている状態で梱包されて
> いるようです。
すると、UNIX Perlで使用するような-u引数でコアダンプさせた実行時イメージとは異な
るものですね。Javaの.classファイル（＋ランタイム）に近いのもですかね。
＃ そうであればコンパイルと云って差し支えないような…。(^^;
しかし、2MBという大きさは（私にとっては大きいですが）一般の方がどう感じられるか
興味ありますね。
実は私も現在、次のリビジョンのテスト中なのですが、またしても構成ファイルが増えて
しまいました。(^^;
サイズの大きいPlug-inとファイル数の多いPlug-in。さてどちらを選ぶでしょうか。
・サイズの大きいPlug-in
・ファイル数の多いPlug-in
・求める機能があれば気にしない
…どうも三番目が正解っぽいような(笑)。
[0214] 00/10/21 17:34 一 五明(YMjHyfzdazU): Re:210)Re:quest quantity
>別にムキになっているのではありませんので悪しからず。f(^^
ある程度いろんな視点はあるでしょうし、各々の作者の判断材料になれば
いいと思ってます(^^;
>一般的に考えるとやはり、リクエストが短時間に集中する状況の方が計算機的にきついと
>考えられますので、断続的なリクエストの方が「まだ」ましだと思います。
うーむ…クライアント側からサーバー側の負荷の増加/減少傾向や高負荷の
持続時間が分からない以上、一般論で考えるしかないですかね。
>> 1ページ1記事形式のツリー系では必要な部分読んだらshutdownしてる
>この時点で、CGIなどのサーバ側のプログラムが終了しているかしていないかはわかりま
>せんので、実際に負荷軽減になっているかは疑問です。
あ、転送量と転送プロセスの占有時間を減らすのが目的です。
CGIそのものの実行時間は変わらないと思います。
>CGIでしたら、出力は一旦httpd（或いはそのspawn）に渡されるので、クライアントが
>ネットワークコネクションを切断したときには（余程出力が長くない限り）既にサーバ側
>プログラムの実行が終了している可能性が大きいと思うのですが、如何でしょう。
この辺詳しく調べてないんですが、CGIをテストしていて、ある程度出力し
てからPerlが実行時エラーで落ちたときに、出力内容は1バイトも送られて来
ずにサーバーエラーが返ってきたことが有るので、CGI出力はバッファに溜まっ
て行って、プロセスが正常終了すれば転送開始、異常終了なら破棄だと思っ
てました。
実際はCGIプロセスの終了待たずに転送開始することもあるんでしょうか？
（サーバーによるのかも）
http://kt.sakura.ne.jp/~timeflow/M/
[0213] 00/10/21 10:22 Buckeye(UnTUYw5MC2c): Re:209)RE: 実行形式プラグインでINCM異常終了
もし万一、INCM側で対処できない場合には、ダイアログ初期化だけフツーの
perlスクリプトで行い、巡回処理はexe形式で行うという方法もあるかもしれま
せん。その場合、「ユーザによる実行キャンセル」やSTDOUTなどの出力切り替え
がうまくいくのかという不安はありますが……
Best Regards,
Buckeye
[0212] 00/10/21 10:22 Buckeye(UnTUYw5MC2c): Re:211)Re: cm_Plug-in.exe
>>試行されたPlug-inは何れの環境でコンパイルされたものでしょうか。
私のexeは、perlスクリプトをActiveState社（ActivePerlを配布している会社）
のPDK（Perl Development Kit）に入っているPerlAppというプログラムでexe化
したものです。いわゆるコンパイルとは違うもののようです。（この処理は、
NT上でしかできない。ただし、できあがった実行可能形式ファイルはWin95/98系
でも実行可能）
PDKによる実行形式化は、必要なperlスクリプトやモジュール、関連するDLLを、
Perlの実行エンジンとまとめてexeに必要なヘッダをつけたもの、というイメー
ジのようです。ファイル内をむりやりのぞいてもテキスト情報はほとんどないの
で、perlスクリプトの部分は中間言語にコンパイルされている状態で梱包されて
いるようです。
こういう形ですから、ファイルサイズは大きくなります。必要なモジュールを全
部まとめてできた実行可能なファイルは、結局、1.7M前後にも達しました。
というわけで、httpsアクセスに必要なものも含めて、ともかく、Perlのモジュ
ールをまとめるだけですから、プログラミングという意味では、どのモジュール
を使っても同じことです。だから、Win32::APIでも現状の形式でも、たぶん、私
にとっては同じことだと思います。（exeに梱包して配布できないモジュールは
使えませんが）
Best Regards,
Buckeye
[0211] 00/10/21 00:33 風葉(/Z7FKywOcl2): Re: cm_Plug-in.exe
> NT4.0+IE5.0だと問題ないのですが、Win95+IE5.0ではダイアログ初期化でINCMペ
何も情報源がありませんので、大したことをお訊き出来ませんが、私も.exeを使っている
以上、気になることがあります。
試行されたPlug-inは何れの環境でコンパイルされたものでしょうか。
全く参考になりませんが、私の場合はVC++6(NT5+IE5)で作成しました。
生憎とWindows98環境は残っておりませんので、実際に動作しているかは不安です。
＃ が、どなたからも反応がないので益々――。(-_-;
今回.exe配布されるとのことですが、これは必要となるモジュールが標準のものでないと
いうことは拝見致しましたが、.exeに拘っておいででしょうか。
そうでなければ、https部分をWinInet APIにやらせてしまう方が「楽」だと思います。
＃ あ、でもPerlのみでWinInetを使おうとするとWin32::APIが必要になりますね…。
[0210] 00/10/21 00:18 風葉(/Z7FKywOcl2): Re:quest quantity
別にムキになっているのではありませんので悪しからず。f(^^
> 予想ですが、サーバー負荷が問題になる状況では、あちこちからリク
> エストが掛かる状態が長時間続くわけで、そういう状況だとちょっとず
> つ長時間読むのも、短時間で読み込み済ませて他からのアクセスに帯域
> 譲るのも、ほとんど変わり無い気がするんですが、どうなんですかね…？
（Apacheでは（恐らくNCSA httpdやCERN httpdでも）複数のhttpd、4〜5プロセス位が常
駐していて、リクエストが来るとspawnする仕組みになっていたと思います。
＃ かなり怪しいです。(^^;
NetscapeやIISとなると（調べたこともないので）さっぱりです。
一般的に考えるとやはり、リクエストが短時間に集中する状況の方が計算機的にきついと
考えられますので、断続的なリクエストの方が「まだ」ましだと思います。
> 1ページ1記事形式のツリー系では必要な部分読んだらshutdownしてる
> ので、平均3/5程度しか読んでないはずです。画像も読まないですし。
う、私のPlug-inは最後まで読み込まないとパーザに掛けていません。(^^;
＃ メッセージが途中で切れていると困りますし。(^^)b
＃ …ごめんなさい。実はモジュールが対応していないだけです。f(^^
本題。
この時点で、CGIなどのサーバ側のプログラムが終了しているかしていないかはわかりま
せんので、実際に負荷軽減になっているかは疑問です。
CGIでしたら、出力は一旦httpd（或いはそのspawn）に渡されるので、クライアントが
ネットワークコネクションを切断したときには（余程出力が長くない限り）既にサーバ側
プログラムの実行が終了している可能性が大きいと思うのですが、如何でしょう。
> 纏読館のアクセスカウンタにこの機能付けてます(^^;;;
ご苦労さまです。
私も昔やっていましたので。(^^ゞ
＃ やはり次に弄ばれ（てい）るフィールドはSet-Cookieですね(笑)。
[0209] 00/10/20 11:11 Buckeye(UnTUYw5MC2c): Re:191)RE: 実行形式プラグインでINCM異常終了
これ、やっぱり発生します。
NT4.0+IE5.0だと問題ないのですが、Win95+IE5.0ではダイアログ初期化でINCMペ
ージ違反が発生し、異常終了します。Windowsを立ち上げなおしてみても、状況
は変わりません。巡回はNTでもWin95でも問題なくできます。
Win95しか持っていない人はダイアログ初期化ができないということになっちゃ
うんで、これ、まずいですね。ダイアログ初期化と巡回で、プラグインの実行形
式に何か違いがあるんでしょうか？
Best Regards,
Buckeye
[0208] 00/10/20 09:23 一 五明(YMjHyfzdazU): Re:207)リクエストの間隔と総量
>ただ、クライアント側から見れば何れも同等のリクエストと見倣せるとは思いますが、
>サーバ側の処理量は明らかに異なります。
「リクエスト間隔の短さ」が問題になるのは、同時平行して複数リク
エスト掛けるのが問題（高負荷）という意味に取ってましたが、リクエ
スト数/転送量の総量が変わらないとして、１リクエストが終了してから
次のリクエストを掛けると言うアルゴリズムの場合でも、その間隔が短
いと負荷が増えるんでしょうか？
（Yahooはオプションで2リクエストまでは同時平行しますが(^^;）
予想ですが、サーバー負荷が問題になる状況では、あちこちからリク
エストが掛かる状態が長時間続くわけで、そういう状況だとちょっとず
つ長時間読むのも、短時間で読み込み済ませて他からのアクセスに帯域
譲るのも、ほとんど変わり無い気がするんですが、どうなんですかね…？
（サーバー負荷が収まる時間帯まで引っ張れば話は別ですが）
転送量の総量に関しては、INCMプラグのほうが少ないはずです。
1ページ1記事形式のツリー系では必要な部分読んだらshutdownしてる
ので、平均3/5程度しか読んでないはずです。画像も読まないですし。
>昨今の計算機性能でこれが問題となるかは判りかねますが。
これは塵も積もれば…というやつで、十分なっているようです。
1ページ1記事でしか読めない掲示板は勘弁してほしいところではあり
ますね。せめてgeoboardみたいにHTML書き出し形式にしてCGI通す必要の
ないようにしてほしいです。
>「このページを参照しているページ」などと、Refererから抜き出したURLを並べていたり、
纏読館のアクセスカウンタにこの機能付けてます(^^;;;
http://kt.sakura.ne.jp/~timeflow/M/
[0207] 00/10/20 00:40 風葉(/Z7FKywOcl2): Re: /robots.txt
> 言えるかどうかは別にして、これはブラウザとのアクセスを区別する根拠に
> なるのでしょうか？ 単にリクエスト間隔だけなら、ブラウザで複数画像貼っ
> たページ開いたときにも同じことが起きます。
確かに、ページ内コンテンツのリクエストについては失念しておりました。更に、往々に
してこちらの方がサイズも大きいですね。
＃ そういえば、かつてのMosaicはページ内の画像を全て読み終えるまでレイアウト
＃ （＝表示）出来ませんでしたね。画像表示はオフにしていましたよ。
ただ、クライアント側から見れば何れも同等のリクエストと見倣せるとは思いますが、
サーバ側の処理量は明らかに異なります。
画像などの場合、単純にhttpdがファイルシステムから参照したものをそのまま送るとこ
ろを、INCM Plug-inの対象とされるリソースの殆どはサーバ側の何らかのプログラムの
実行結果です。
つまり、サーバが後者のリクエストを受けたときの処理量の方が前者のそれよりも大きい
ので、集中的にリクエストを受けるのは負荷になると思います。
＃ 下手をするとサーバアタック…と見倣されるのですかね。(^^;
昨今の計算機性能でこれが問題となるかは判りかねますが。
> >何と。いつの間にRFCになっていたのですか。何番でしょうか？
> >サーチエンジンに「RFC Robot」と掛けてみましたが引っ掛かりません。
>
> あ、これはうろ覚えなのでかなり怪しいです(^^;
先に挙げたWebCrawlerの作者M. Koster氏によるドラフトでしたら四つ、存在はしている
ようです。ただ、既に数年前に期限切れとなっていて久しいです。
＃ 実はこれも読んでいませんが。(^^A
> Refererといい、何かいたちごっこみたいですね。
黎明期には（というよりも確かRFC1945でも）このフィールドは任意で、当時のMosaicも
リクエストには付加していませんでした。
＃ そんな頃からCGI書いていたのか…。
で、その頃現れた「Netscape Navigator 1.12N」に乗り換えたと記憶しています。こちら
はRefererを付けていたと思います。多分。(^^;
「このページを参照しているページ」などと、Refererから抜き出したURLを並べていたり、
「このエージェントは云々」などと、User-Agentとその批評をずらずらと書き連ねている
ページを見かけると可哀相になります。ご苦労さま。
[0206] 00/10/19 11:12 でぐ(MVbPwfyRCtk): Re:98)RE: 詳細設定
毎々お世話になっております。
> ↓だいぶ前に書いたものですがこんなテキストもあります。
> http://www.gld.mmtr.or.jp/~naofumi/incm/file/incm_bbs_ini.txt
<タイプ>に「TD: テキストボックス(数字のみ)」というのがあるのですが、TSと同じように思われます。
数字以外の文字列を入力でき、incm_BBS.iniにも書き出されてしまいました。
次のVUpの際にでも、これは数字以外入力不可にしていただけないでしょうか？
http://degitian.portland.co.uk/index.xml
[0205] 00/10/19 09:15 一 五明(YMjHyfzdazU): Re:204)Re: /robots.txt
>ツリー形式のようにHTTP Requestを短い間隔で大量に発行すると思われる掲示板巡回では
>Robotといえるのではないでしょうか。
言えるかどうかは別にして、これはブラウザとのアクセスを区別する根拠に
なるのでしょうか？ 単にリクエスト間隔だけなら、ブラウザで複数画像貼っ
たページ開いたときにも同じことが起きます。
ロボットが足枷をはめられる根拠としては他に、ロボットで取得したページは
人間が見てない場合が有る、というのが有りますが（ブラウザでも例えば縦長の
ページでページの下のほう見ずに上のほうのリンクでどっかに飛ぶケース等は多
いので個人的には疑問ですが）、掲示板巡回の場合読みたいから取ってくるので
あって、見てないというケース（読み切れない等）は無いとは言いませんが、ブ
ラウザのそれとの確率比較で言えばこれには該当しないと思います。
>何と。いつの間にRFCになっていたのですか。何番でしょうか？
>サーチエンジンに「RFC Robot」と掛けてみましたが引っ掛かりません。
あ、これはうろ覚えなのでかなり怪しいです(^^;
前に何度か、規約がどうとかうるさく書かれてたのを見た覚えはありますが、
インターネットの規約＝RFCのようなイメージがあるので勘違いかもしれません。
>私は利用していないのでログを公開していた管理者ページからの情報になりますが、かの
>「WWWC」は「User-Agent: WWWC/1.00」と名乗っているようです。
これは知ってました。
今見てみたら、Mozillaに指定するオプションも無いようですね。
ちょっと調べてみたのですが、どうもMozillaでない場合の制限はサーバー単
位では、旧バージョンのHTMLソースを返して来るのが主体で、リクエストその
ものを切るケースはほとんど無いようです。
ただし、YahooのMyYahoo!サービスのように、サーバーは通してもCGIで却下の
タイプはあるみたいです（Yahoo掲示板はMozillaでなくても大丈夫なんですが）。
WWWCの場合、あまりCGIはチェック対象にしない（負荷が大きいのでなるべく
避けることを推奨している）ので、オプションも付けてないのだと思います。
確かに通常は自称で、オプションでMozilla可が望ましいかも知れませんね。
>「User-Agent」が無効化した昨今、そのうち「X-Mozilla」なるフィールドが出来るかも
>知れないですね(笑)。
Refererといい、何かいたちごっこみたいですね。
http://kt.sakura.ne.jp/~timeflow/M/
[0204] 00/10/18 23:49 風葉(/Z7FKywOcl2): Re: /robots.txt
> ユーザーが指定したところから拾ってくるのを、動かしている本人
> にもどこから拾ってくるか判らないサーチエンジン等と同列に置ける
> かどうかは疑問です。
ツリー形式のようにHTTP Requestを短い間隔で大量に発行すると思われる掲示板巡回では
Robotといえるのではないでしょうか。
＃ 今は一応、2秒ウエイトを入れています。
> ただ、どっちにしろ（GAEさんはどうか知りませんが）、私はRFCの
> ロボット規約だか何だかは納得行かないものがあるし、あれを全面改
> 訂して自動巡回の市民権の確立するのが夢の一つです。
何と。いつの間にRFCになっていたのですか。何番でしょうか？
サーチエンジンに「RFC Robot」と掛けてみましたが引っ掛かりません。
私はRFC1945と例のwebcrawlerサイトの情報を元に、3〜4年前に作った知識のまま現在に
至っているので…。(^^; 自分のサイトから放っていたRobotもこの状況。f(^^
＃ ちゃんと調べないと駄目ですね。
> Mozilla以外のリクエストを却下するサーバーが結構あるみたいなので
それは存じませんでした。これに関しては次のリビジョンでPlug-inのプロパティで設定
出来るようにしようと思います。
「/robots.txt」のチェックに関してもデフォルトでは有効になっていて、弾かれた場合
には無効に出来るようになっていますので、これと揃えて。
強制ではないにしろ、Robotに対するマナーがあることを知ってしまっている以上は少な
くともデフォルトでは従うようにするつもりです。
＃ そうなるとMETAタグも…。
参考までに。
私は利用していないのでログを公開していた管理者ページからの情報になりますが、かの
「WWWC」は「User-Agent: WWWC/1.00」と名乗っているようです。
「User-Agent」が無効化した昨今、そのうち「X-Mozilla」なるフィールドが出来るかも
知れないですね(笑)。
あぁ、HTML1.0をMuleで書いてMosaicで覗いていた時代が懐かしい。
＃ あ、勿論今もEmacs(Meadow)で書いてますが。
[0203] 00/10/18 09:30 一 五明(YMjHyfzdazU): Re:200)RE: /robots.txt
>ところで、GAEさんには先日メールにてお伝えしたのですが、巡回という操作は、人間が
>行う閲覧とは違い、機械的な処理であるので、Webロボットとしてのマナーに従うべきで
ユーザーが指定したところから拾ってくるのを、動かしている本人
にもどこから拾ってくるか判らないサーチエンジン等と同列に置ける
かどうかは疑問です。
ただ、どっちにしろ（GAEさんはどうか知りませんが）、私はRFCの
ロボット規約だか何だかは納得行かないものがあるし、あれを全面改
訂して自動巡回の市民権の確立するのが夢の一つです。
巡回クライアントの側に問題が問題が無いとは言いませんし（例えば
同一サーバーに同時に20も30もリクエスト掛けるような非人道的な？
ダウンロードツールがあるとか）、そういうのは改善する努力も必要
ですが、それ以前の偏見というのも相当に感じます。
「悪法も法であり、それと戦うなら法を遵守した上で、法の範囲内で
戦うべき」と言えばそうかもしれませんが、私はそこまで人間出来てな
いです。すみません。
>少なくともMozillaを名乗ることは止めるべきだと思います。
Mozilla以外のリクエストを却下するサーバーが結構あるみたいなので
これは仕方ないのではないでしょうか。私だって自分の作ったプログラム
が人の名前借りなきゃならないのは悔しいですよ…。
サーバー管理者側の偏見のほうが無くなれば、（意図的なクラックは
別にして）各自自分の名前を名乗るようになると思います。
http://kt.sakura.ne.jp/~timeflow/M/
[0202] 00/10/18 09:30 一 五明(YMjHyfzdazU): Re:201)RE: ユーザキャンセル時のあとかたづけ
>巡回時にユーザによって中断されたとき、何らかの終了処理をしようとPerlのシグナル
>ハンドラを設定して待ち構えていたのですが、何もシグナルを捕らえられませんでした。
>ENDセクションは勿論のこと、$SIG{'DEFAULT'}ですら駄目だったのですが、どのように
前にそういう話が出てましたが、$SIG{'INT'}で駄目でした？
結局うやむやになって実装されてないかも知れません。
>…こちらの掲示板もスレッド形式の方が便利ですね。
INCMで読む限りはどちらでも同じだと思うんですが、ブラウザで読む
場合にも配慮したほうがいいですかね？
http://kt.sakura.ne.jp/~timeflow/M/
[次のページ]