fumbleのネットワーク周りを考える

　なぜか、fumble-minchaをつなぐ部分を作成したわけですが、いまのところ、fumbleとみんちゃAPIが結構強く結合をしています。それにともない、fumble側の動作自体も、みんちゃのAPIにひきづられてます。それは、まぁ、悪いことではないんですが、そこにさらに「汎用ツール目指しているんだから、おーにちゃっとやＩＲＣとかにもつなぎたい」とかの話をする人もいるわけです。
# 「いきあたりばったり」で作るのか、「最終形を念頭において」作っているのか、いまいちはっきりしない。なんか、また全改定するっぽいし。どっちかとゆーと、あまりに機能をはしょりすぎて、みなで使うツール目指して　というよりも、開発者のおもちゃと化しているだけな気がする。

　とりあえず、fumbleからみたネットワーク機能と、みんちゃが提供している（みんちゃ固有の仕様）を、独立して考えるために、「fumble側に」汎用的な、「fumble側が期待する」interfaceを１つ作成した上で、そのinterfaceと、実際のみんちゃ接続クラスを橋渡しするクラスをはさみたいところ。このinterfaceを考えるのは、本体側を待ちます。どうしたいんだか判らないし、先にいじっても、なんか、全改定する気みたいだし。そもそも、今後どうしたいのか見えないし。

　その際にどーしても避けて通れないのは、「fumble側で機能の有無を取得して処理を変更する」という機能。たとえば、みんちゃには、SEND(PRIVMSG)がない。正確には外部アプリに送信・取得するAPIを提供していない。そのため、いまのところ、fumbleの本体全体に受信モード/送信モードという概念が無い。そのとき、どう動作するかは、adapterクラスの実装によるわけです（送受信モードといった概念自体は導入しておく必要がある）
# 送信モードは、%2 とか書くと、SENDで結果が飛んでいったアレです。手札表示とかでも、内部で使ってます。
# 受信モードは、SENDで受信したコマンドや、通常発言のコマンドにたいして、とくに送信モードを指定しない場合に、同じ方法で返信するための記憶してます。
# あとは、動的にコマンド入力者を変えるのもよくつかってました。「＞ほげほげ」という書式のアレです。これも受信モード・・・？「＞」とすると、元に戻ります。

fumble-更新中

　ちまちまと更新中。主な目的は以下の通り。
・文字列の表記である"や、括弧の対応をもって、コマンドとして扱う。
　→途中に半角スペースがあったり、文字列中に括弧があっても誤動作しないように。

・COMMANDのform部分の処理の変更
　関数の形式で制御構造を扱うのは無理があるため。

今週末ぐらいに出来るとよいなぁ　と思わなくもない。
※_ifや_whileを使っているformの定義ががらっと変る・・・かも。とりあえず、制御構文は、if-elseとwhileのみ。

telnetベースのチャットシステム

　いろいろ考えて、とりあえず、telnetベースのチャットを完成させようかということに。
理由は以下の通り。
・おーにちゃっとさーば互換に出来る
・プロトコルが規定済み
・NA2が使える
・現状のfrpgs.clientに限れば、ユーザがコマンド体系になれている。

ただし、現状では同じtelnetベースであるおーにちゃっとサーバは、１部のセッションを除いて使用されていない。以下の理由が考えられる。
・サイトとして推奨はしていないこと（いちおー、推奨ツールはみんちゃ）
・サーバの導入の大変さを、利用する上（クライアント）での大変さと誤解されている（説明ページの不備）
・フリーで良いクライアントが無い
・新規ユーザを呼ぶ場合、コマンド体系に慣れてない
・クライアントユーザが、接続するのが大変（ＩＰやらなんやら）

なので、以下のようなものを想定
・サーバ兼クライアントで１つのプログラムにする
・ユーザ一覧リストを表示し、SENDはそこからGUIベースに行えるようにする
　※ただし、実際のユーザ一覧とずれる可能性があるのはあきらめる。
・メタサーバ（みんちゃのリンカー）相当を導入する
・接続に必要な情報・手続きを簡単にする（接続先ごとの管理を必要ないようにする）

とりえあず、サーバ兼クライアントで通信可能なものを、ここにのせてみたり。
メタサーバの実装と、情報の簡略化は、まだ。
# いまが、おーにちゃっとと同じぐらいの設定の複雑さ。