[前のメッセージ (日付順)]  [次のメッセージ (日付順)]
[前のメッセージ (スレッド順)]  [次のメッセージ (スレッド順)]
[日付によるインデックス]  [スレッド・インデックス]  [記事検索]

servers and clients



 三田です。


 emacs 上以外でも動く各種のクライアントや、目を見張るような機能を登載
したサーバが数多く開発されていて喜ばしい限りなのですが、その一方で、ユ
ーザレベルでは必ずしもその恩恵は享受できていないのではないかと思える部
分も出て来ました。

 何らかの新機能は、新しいサーバとして登場するか、どれかのクライアント
の一部として実現されることがほとんどなので、少し試してみても、結局は自
分が一番必要としている機能を持ったサーバとクライアントを使い続けること
になる場合がほとんどなのではないかと思われます。


 早い話が、

    ・複数辞書の検索
    ・辞書の再読込
    ・電子辞書(EB)の検索
    ・外部プログラム(MeCab・PRIMEなど)の呼出
    ・曖昧検索
    ・高速化(CDBやcacheなどによる)
    ・接頭辞・接尾辞自動変換
    ・かな見出しによる数値変換
    ・ユーザ辞書の管理

 などなどの機能のうち一つか二つを持ったサーバが多数あるよりも、それら
を一通り全て持ったサーバが一つある方が、一般的な利用者にとってもクライ
アントの開発者にとっても遥かに便利になるのではないかということです。

 もしそうしたサーバが一つあれば、クライアントの側ではサーバとの通信機
能さえ実装すれば済み、車輪の再発明を避けて、開発資源をユーザインタフェー
スに直結した部分に集中させることができるでしょう。

 また、あるクライアント(DDSKKも一つのクライアントですね)に機能を実
装しても、それはそのクライアントでしか利用できませんが、同じ機能をサー
バに実装できれば、サーバと通信できる全てのクライアントから利用可能にな
ります。これは、全てのクライアントに実装したのに等しい効用です。


 この「キッチンシンク的」サーバを実現する手法として、機能をモジュール
化したサーバを作り、新機能は新しいサーバではなくそのモジュールの一つと
して実装するようにするのが良いのではと思われます。利用者は、必要なモ
ジュールだけを動かすように設定するわけです。具体的には、rskkservが EB
検索を実装している手法がこの原形になり得るのではと思っています。

 あるいは、SKKサーバと通信できるSKKサーバ(SKKメタサーバ)を用意し、
利用したい複数のSKKサーバをそれぞれ別のポート番号で走らせておいて、ク
ライアント→SKKメタサーバ→各SKKサーバと問い合わせるという手法も考えら
れます。他サーバとの通信機能も、キッチンシンクサーバのモジュールの一つ
にしてしまえばさらに良いでしょう。


 逆に、DDSKK はサーバなしでもほとんどのことができる、キッチンシンク的
なクライアントとも言えるので、普段 DDSKK のみをお使いの皆様にはほとん
どメリットが感じられないかもしれません。しかし、ひとたび emacs を離れ
ると、それらの機能の実現には莫大な労力がかかってしまうのは skkinput3
や skkime などで実証済です。サーバにできることと、クライアントにしかで
きないことを明確にすることは、SKK のコミュニティ全体にとって小さからぬ
意味を持ち得ると思われます。


 まとめると:

・各種機能をできるだけ少数のサーバに集約する、または
・複数のSKKサーバに問い合わせる機能を持つメタサーバを作る
・サーバとクライアントのどちらにでも実装できる機能は、サーバに実装する
・全てのクライアントは可能な限り早い段階でサーバとの通信機能を実装する

 という方向性が望ましいと私は考えます。


 以上、一ユーザとしてのわがまま・妄言でした。

 実装という面では私は何もできませんが、アクティブに各種サーバやクライ
アントを開発しておられる方や、これから何か実装してみようとなさる方が、
方向性を定めてゆく上での踏み台にでもして下さればということで書かせてい
ただきました。あなたのコードが、一人でも多くの人を幸せにできるように。


================================================
三田祐介(key/clefs) <clefs@xxxxxxxxxxxxxx>