IRCクライアントを作った上での

非常に技術的なグチ

及びJCTCP要領解説(おまけ)


いやぁIRCクライアントをJAVAでシコシコ作りましたよ。
作ってて思ったんですけど、このプロトコルって、ぜんぜん

ダメじゃん

え?Jarkko Oikarinen さんよ。


いや、一応、Jarkkoちゃんの名誉の為に言うならば、
IRCが発明された当時はきっとテキストベースのクライアント
しか無かったのでしょう。
だから、あの様な手打ちコマンドを優先させるコマンド体系は
当時は正義だったはずです。でも・・


なんであんな古いプロトコルが現代でまかり通るかな?

ってゆーか


誰も改定しようとしないの?


みんな当然の如く受け入れて作っちゃう訳?

信じられない!!


あんなぐちゃぐちゃなコマンド体系使ってるから

サーバーも重い作りしか出来ないんじゃないの?


少なくともバグを押さえるクライアントを作るのは、ちょ〜労力がいるぞ?
まして、JAVAアプレットだよ?
 スピード命ぃのメモリー使用量命ぃのガベージ軽減命だよ?


定形フォーマットにしろよ!!

そんで

体系化しろって!!


スマートなトークン解析させろよ、まじ。



いやぁ〜、作っててほんと、あったま来ました。

これが今のRFCのレベルかい? 


ひっきぃ〜


データ転送量がうんたらかんたら言うだろ?どーせ。

知ってる?

ブロードバンドって言葉


何を言っても聞く耳持たんぞ俺は

断固として異を唱えてやるぅ!


それから

CTCPだよ、おまえ


誰が作ったのか知らないけど


なんでWhisperとぶつけるかな?


Away mark up と
思いっきりぶつかってるじゃん!!


ってゆーか


なんでNOTICEで統一しないかな?!


SVERSION RVERSION とかで送受信を区別すりゃ済むじゃん!



これが現代のITをリードしてる人達の技術?



ひっきぃ〜!!


ちゅう訳で、JAIRCは少なくともCTCPに関しては
NOTICE統一プロトコルも実装しました。
JAIRC同士なら、仮にAway mark up されていても不在メッセージが届く事は有りません。
(CTCP問い合わせ中のユーザだけ、返答が来るまで301をバイパスさせるって手段も
有りますが、基底プロトコル中にそんな姑息なフラグ判断を入れたく有りません。)
少なくとも、日本のIRCクライアント屋さんは追随してくれる事を望みます

仕様は単純にPRIVMSGを使わず、NOTICE統一にしただけです。
リクエストコマンドは頭にSを付加+コマンド、返答コマンドは頭にRを付加+コマンドです。


例:VERSION の場合

相手のクライアントのバージョン要求
NOTICE tagetUser :\x0SVERSION\x0

相手からのクライアント情報要求応答
NOTICE myNick :\x0RVERSION :ProgramName:Version:ClientInfo\x0

ちなみにRVERSIONの受け取り時は ":"セパレータ一発でトークン解析出来る様に、
RVERSIONの後に ":"を追加してあります。

本当はIRCコマンドも全部 ":"セパレータ化&定型化したい所ですが今回はCTCPだけです。
(IRCコマンドについて少し言及するなら、発信元はトークン[0]、コマンドはトークン[1] に必ず有り、
送信先にチャンネル名が無ければトークン[2]は1スペース、有れば必ずトークン[2]に。
送信先にニックが無ければ トークン[3] は1スペース、有れば必ずトークン[3] に。
発言系パラメータが無ければトークン[4]はブランク、有れば必ずトークン[4]に・・・
まぁ、実際はこんな単純には無理でしょうが、時間を掛けて考えればそれに近い形で
整理出来るでしょう。)


それと、返答コマンドに ":" を追加したのは他に

SOURCE
ERRMSG
PING

の3つです。

ふざけた事に、
FINGER
CLIENTINFO
TIME
の3つは、最初からコマンドの後に ":" が有るので、
これらは単に頭にRを付けてやるだけです。


わかりますか?

この統一性の無さ!!


尚、TIMEはパラメータの時間情報に ":" が含まれる(HH:MM:SS)事が一般的なので
注意が必要です。

それから、話が前後して申し訳有りませんが、リクエストコマンドでパラメータを持ってる
ERRMSG
PING
の2つは、スペースセパレータで問題なくトークン解析出来ますが、
仕様の統一性が有った方がロジック的に有利なので、これらも、コマンドの後に
":" を付加して有ります。


特殊系で「ACTION」が有ります(これは要求返答と言う性格では無い)が、
これも仕様統一の為に ":" を付けました。
しかし、ACTIONは、パラメータの発言文字列に ":"が含まれてる可能性が高いので
トークン解析関数は使わずに切り出し処理をする必要が有ります。
(まぁ、これは元々スペースでもセパレート出来ない性格な物なので我慢して下さい)

あと本当は、CTCPコマンドも数字文字列化したコマンド体系にした方が
文字→数値変換+case分岐と言うロジックだけで済むので、速度性能及び
メモリー効率を上げられるのですが、まぁ、分かりやすさと言う点で、単語ベース
のコマンドだって事までは強く否定するつもりは無いです。


でも、CTCPを手打ちで実行する奴は今時いないだろ?

と思うので、出来れば数値コマンド化したいかな?

まぁ、この辺はなるべく皆との統一見解で行きたい所なので保留しときます。


既に立派なIRCクライアントを作ってる方々なら、以上の説明で
「よしっ分かった!」と思ってくれるでしょうが、もしも「もっと具体的な話が無いと
分からないよぉ」って人がいたら要望を上げて下さい。
変更CTCPコマンド体系一覧を作ります。(作りました)

尚、このCTCP体系を勝手ながら JCTCPと名乗らせて頂きます。
あと、勝手ついでに幾つかコマンドをリザーブしました。

ICON
SOUND
MOVE
VOICE
VCLIP
EFFECT
(上記6つの具体的な仕様は未定、但しICONはアバターキャラ用で、絵文字用では無い)
JCTCP
(SJCTCPを送って相手がJCTCPをサポートしているかチェック、RJCTCPが返ってくればOK
参加者一人一人をクラス化して管理し、チェックは1回で済ませたい所)

今回は JAVA Appletと言う性格上、DCCはサポート外なのでその辺は一切
勘案してません。 今後必要が有れば盛り込みたいです。


でもいい加減、CTCP位はIRCコマンドレベルでサポートしたい・・・
今後NOTICEが拡張された際に、何かとぶつかる可能性も有りますので。

この記事に関するご意見・ご感想はこちらまで! どしどしお寄せ下さい。

<トピック一覧に戻る>