★ INCM Plug-in開発掲示板 ★ TinyGrass Ver0.32a ［戻る］
[0237] 00/10/25 19:15 たこぽん(CJFZWVajOk2): Re:232)うまくいきました
一五明さん、風葉さん、ありがとうございました！
うまくツリー表示されるようになりました。
（できたプラググインは、光が丘ウォーカーという、東京都練馬区ローカルな掲示板です。
自主開発のようです。
こんなローカルなプラグイン、公開しても誰も要らないですよね！）
たこぽん
[0236] 00/10/25 07:43 一 五明(YMjHyfzdazU): Re:232)Re: thread
>というのも、きちんとツリー表示されているフォルダーから cmt.001 を持ってきてもツリー表示されないのですが、incm_BBS.ini を持ってくるとツリー表示されるものですから。。。
cm$の出力には問題無かったようですね(^^;
タイトル一覧の上の「No.」の所を何度かクリックすれば、番号順に
なったりツリーになったりしますが、その状態が記録されていただけ
です。
http://kt.sakura.ne.jp/~timeflow/M/
[0235] 00/10/25 07:39 一 五明(YMjHyfzdazU): Re:233)RE: ツリーは
>私、Emacs派なのでMeadowを使っているのですが、INCMにエディタ設定してもメッ
>セージを書いた後、何も起こらないのでINCMから投稿・返信が出来ないのです。
いや、ブラウザ書き込みでも、タイトルを「>233 返信タイトル」のように
記述（「Re233 タイトル」等も有効）すればINCMで見たときツリーを繋げるこ
とは出来るんですが…(^^;
http://kt.sakura.ne.jp/~timeflow/M/
[0234] 00/10/25 00:02 風葉(guZ8nsXcxwU): Fw: まとめて返信してごめんなさい。
> 「/robots.txt」に記述するだけで（この表記に従っている）Plug-inを防ぐこと
> が出来ますので。
この部分を――
「/robots.txt」に記述するだけで（この表記に従っていて、尚且つ「/robots.txt」
に従っている）Plug-inを防ぐことが出来ますので。
――と訂正します。d(^^;
[0233] 00/10/24 23:56 風葉(guZ8nsXcxwU): まとめて返信してごめんなさい。
> # INCMで見てもツリーが切れてて辛いのです。
> # 返信を使ってもらえると助かるのですが・・・ブラウザから書くと面倒？
ごめんなさい。犯人です。(^^;
私、Emacs派なのでMeadowを使っているのですが、INCMにエディタ設定してもメッ
セージを書いた後、何も起こらないのでINCMから投稿・返信が出来ないのです。
＃ Meadowで投稿・返信されている方、いらっしゃいませんか？
> どうやら“カラーラベル”機能の情報のようです。
メニューにある「記事→カラーラベル」のカラーラベルですね。
あれはどのように使うのでしょう。指定しても色が付かないのですが。f(^^)
> タイトルの文字色も変わった方が、見やすいと思うのですけど。。
幾つかの掲示板ではタイトル文字の色を選択が出来るので出来れば欲しいですね。
＃ 本文の色を変更出来るものも恐らくあるでしょうし。
> そういえば、BBGGRRになっていたような・・？
え"。
まずいです。公開中のPlug-inの内二つは「#RRGGBB」で記録しています。(xx)/
> 読み込みの時ですが、INCM自体はロボットではないので、
私もUser-Agentフィールドを設定するときにそれは考えました。
確かに接続処理諸々は全てPlug-inの所業ですが、INCMが呼び出しているので、
一番最初に記述しています。
> 例えば風葉さんの例の場合なら"Falcom(INCM Plug-in)/2.03"が良いかと思います。
> ＃RFCを読んでないので迂闊なことは言えませんが。（苦笑）
RFC1945を読んだ当時の記憶によると(笑)、自分を示すシンボルの後には、利用
しているライブラリなどのシンボルを連ねるそうです。
＃ LWP実装ではどうなっているのでしょう？
サーバ管理者もINCMによる巡回取得を排除する場合には、「Disallow: INCM」と
「/robots.txt」に記述するだけで（この表記に従っている）Plug-inを防ぐこと
が出来ますので。
このようなこともありましてINCMを含めています。如何でしょうか。
因みに、ブラウザで主流となっている括弧付きの表現は（RFC822でいうところの）
コメントの意味です。
ですので、せざーるさんの挙げられたような括弧直後に「/version」表記は正し
くありません。
＃ しかし、RFC1945(HTTP/1.0)の後、RFC2068,RFC2616(HTTP/1.1)が発表されて
＃ いますので変更されてい――る可能性は低いと思います。o(^^A
> 逆にINCMを名乗るとしたら、Plug-inに何らかの形でINCMのバージョンを
> 知らせる必要があります。
私もこの点に関してはPlug-in作成当初よりの懸案でして、当初は外部プログラム
で、現在はPlug-inの.exe側がINCM.exeのバージョンを（GetVersionInfoで）調べ
て「INCM/1.21g」なる書式で変数$INCMに登録してから、本体のPerlスクリプトを
実行するようになっています。
ですので（Plug-in本体だけでも）ファイルが二つに分かれています。(^^;
＃ 処理自体は更に別ファイルのDLLです。(^^ゞ
[0232] 00/10/24 23:45 たこぽん(AvN1uh2D6gY): Re:223)Re: thread
いろいろ試してみたところ、どうも cmt.001 の方ではなく、incm_BBS.ini の法の書き方に何か問題があるようです。
というのも、きちんとツリー表示されているフォルダーから cmt.001 を持ってきてもツリー表示されないのですが、incm_BBS.ini を持ってくるとツリー表示されるものですから。。。
この場合、どうすれば良いのでしょうか？ 何かヒントでもお願いいたします！
[0231] 00/10/24 16:35 でぐ(MVbPwfyRCtk): Re:220)RE: Win32::Internet
なんだか最近、ここの書き込み量が急激に増えていて、あっという間に過去の話ですが。
> perl\html以下のフォルダを順次眺めていって、昨日、ちょうど
> みつけたところです＞Win32::Internet
実は「Perlモジュール活用ガイド」という本に載っていてので、存在は知っていました。
ところが、同じページにこんな注意書きもありました。
> WindowsNTでWin32::Internetを使うと問題が生じた。筆者が
> Win32::Internetモジュールをやめて、5章、6章で述べたPerlの
> 標準的なネットワークモジュールを使用しているのは、それが
> 最大の理由である。
これ、私はNT環境がないので、確認できなかったんです。
そこで、これまで使用をためらっていました。
この本の出版から1年半、すでに解決されている可能性も大ですよね。
どなたか、確認をお願いできないでしょうか。
# 冒頭にも書いたけど、最近書き込みが多くてちょっと目を離すと大変。
# INCMで見てもツリーが切れてて辛いのです。
# 返信を使ってもらえると助かるのですが・・・ブラウザから書くと面倒？
http://degitian.portland.co.uk/index.xml
[0230] 00/10/24 07:46 せざーる(541Z76wyXQ2): Re:228)Re: C: I:
>> 色は、S:の属性の次に RRGGBB 形式で記述します。
>> といっても、文字色ではなくアイコンの色になってしまいますが(汗)
>ということは、頭に「#」があると問題があるのでしょうか。(^^;
>＃ しかしアイコンの色って…？
どうやら“カラーラベル”機能の情報のようです。
タイトルの文字色も変わった方が、見やすいと思うのですけど。。
そういえば、BBGGRRになっていたような・・？
[0229] 00/10/24 07:45 せざーる(541Z76wyXQ2): Re:200)User-Agent (Re: /robots.txt)
> Plug-inを作成するにあたり、幾つか無作為にソースを眺めさせて頂いたのですが、HTTP
> Request中のUser-Agentフィールドの値が例によってMozillaを詐称しているのには驚きを
> 禁じ得ませんでした。
>User-Agent: INCM/1.21g Falcom/2.03
>
>――と、INCMとPlug-inの名前とバージョン（リビジョン）をRFCに準拠した書式で名乗ら
>せています。
書き込みの時はちゃんと"INCM/1.21g"と名乗ってるみたいですね。
読み込みの時ですが、INCM自体はロボットではないので、
例えば風葉さんの例の場合なら"Falcom(INCM Plug-in)/2.03"が良いかと思います。
＃RFCを読んでないので迂闊なことは言えませんが。（苦笑）
逆にINCMを名乗るとしたら、Plug-inに何らかの形でINCMのバージョンを
知らせる必要があります。
その場合なら、
print "User-Agent: $cliantinfo $0/$version";
という形にできれば楽でしょう。
＃一応、Plug-inの汎用性を考えて、
＃print "User-Agent: INCM/$incmver $0/$version";
＃にはしませんでした。
[0228] 00/10/23 23:44 風葉(/Z7FKywOcl2): Re: C: I:
Re: C: I:
> CMTプラグインが古いと消えてしまいます。
cm_CMT(INCM Text).exeは1.06です。ダウンロードページにあったセットに同梱
のものでしたが、これは古いものでしょうか。
の…？ Plug-inが出力した.cm$はcm_CMT(INCM Text).exeが再び処理していると
いうことでしょうか。
＃ 重複検査やソート処理を行っているのかな。
> 色は、S:の属性の次に RRGGBB 形式で記述します。
> といっても、文字色ではなくアイコンの色になってしまいますが(汗)
ということは、頭に「#」があると問題があるのでしょうか。(^^;
＃ しかしアイコンの色って…？
P.S.
INCM@HOME 200,000アクセス突破おめでとうございます。
＃ …でも情報が二十日程止まっていますね。f(^^)
[0227] 00/10/23 17:50 GAE(3nxWzOCXjo.): Re:223)記事番号は31bitです
>因みに、拙作cm_Falcom.exeではメッセージナンバーを1000929144256と、かなりの桁の数
>（実はY2K対応していないFalcom BBSの内部日時表現そのまま(笑)）を使用していますが、
>CMTに変換すると201795090と値が変わりました。(^^;
31bitくらいしか使えません。
文字列扱い(S:sABCDEFG,...)にすれば回避できますが、
インポート時の処理が多少重くなります。
>> また、こうした開発の為の情報（incmのデータ構造など）は、どこかに解説させているのでしょうか？
>確かに資料が乏しいのは否めないですね。実は私もI:とC:の使い方が判りません。(^^ゞ
>＃ cmt_format.txtにも載っていませんし。
>一度、GAEさんにメールにてお訊きしたのですが、ご多忙なようで…。
すみません。内容が濃いメールは1ヶ月くらい平気で溜まってます(爆死)
単純な内容のメールはすぐに返事を書いてますが、
考えて書かないといけないような内容だと、なかなか書けません(汗)
INCM以外にも作りたいものがありますし、
特に最近はパソコンがMPEGのエンコードばっかりしてて使えなかったり、
未消化のメールやらなんやらは溜まる一方です(汗)
Macの方も開発の準備がほとんど整ってるので、こっちの勉強もしたいですし…。
[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
[次のページ]