最近の自分の反省として意見を表にださなすぎ、という事を感じていたので、これからはそこそこには表にだしていくようにしよう。
以前tabateeさんと話した時には、IIIMFにSSLのサポートを追加したらどうか、という話をしたと思うけれど、僕個人的にははたしてSSLのサポートを追加したとしてそれで満足できるのかと常日頃考えていました。現状のIIIMSFは、以前の実装とは異なってたいていの拡張はクラスを追加するだけでできるので、そういった拡張自体はそれほど難しいものではないので、SSLのサポートの追加以外にも、(現状のようにper userでthreadを作成するのではなく)、per user毎にforkする、という実装にすることもわりあい簡単に実装できます。例えばper user毎にforkする実装を適用するようにすれば、ユーザー間のプライバシー保護という面では一歩前進することが可能になるはずですし、それ以外ではtcp_wrappers等を利用してローカルネットワークに接続を制限させて、内部の通信をトンネリングさせる、といった運用をする事である程度のセキュリティは確保することは可能になると思っています(そのセキュリティを確保するために労力を必要とすることが悪だ、という意見も考慮せにゃいけませんが)。
で、そういったものを仮に実装したとして、それでIIIMFに対する不満はなくなるのでしょうか?僕はそういった不満はなくならないと思っていて、その本質は前述したような実装のシンプルさにいきつくんじゃないか、と思ったわけです。
逆に、Anthyの場合は、ユーザ辞書をテキストでもっているけど、セキュリティの観点からみると、管理者がぱっとみですぐわからないようにするために、ユーザ辞書はバイナリデータでもったらどうか、と以前いった事があった気がするんだけど、(いってなかったかな?)。そういったところまではそれほどこだわっていないのかなぁ、と感じたりします。
その辺のところを考えていて前述したとおり、本当は実装のシンプルさと複雑さ、それに付随した機能面の違いなどが本質的な違いじゃないのかな、という結論に達したわけです。たとえば、UIMならば、アプリケーション毎のカスタマイズ、といった作業は実質3行くらいのパッチ(APIが変更になったりするので、それに付随した作業もいりますが)でできるようになりますが、それができるのは、実装のシンプルさゆえであって、もっとそういう面でのアピールができるんじゃないか、と。IIIMFでやろうとすると、UIMのように簡単に実装できるわけじゃないし。
まぁ、実際のところ、入力メソッドといえばまだまだkinput2+cannaが圧倒的に多いんだ、という現状を目のあたりにしてしまうと、もっと議論を積み重ねていかないとただの内輪うけになっちゃうので、(個人的には(近い未来にはそうなるとおもいたいけど)いろんな入力メソッドの実装がデフォルトで用意されて、ユーザが好みで使い分けられるのが理想なのだけれども)、どんな議論でも起こしていかないといけないなぁ、と思う今日この頃です。
Anthy WikiのIIIMFの項目についてちょこっとだけ。
skkinput3(elispインタプリタ内蔵)相当のモジュールを作ろうとした場合、サーバが1プロセスで複数のユーザのelispインタプリタのインスタンスを持てるようにしないといけません。まったくその通りです。ライブラリの中でグローバルなデータ等をもっていると即効で煮詰まってしまう事になります。構造体なりなんなりでくくってあげたりして各ユーザごとにインスタンスを生成できるように 作成しないといけません。これがIIIMFで入力メソッドを作成する際に開発者に複雑さを要求する秘訣です。
Q1. 各ユーザがカスタマイズしたelispファイルは誰の権限でどこに置けば良いのでしょうか?iiimf-skkと絡めてかいてしまいますが、iiimf-skkはlinuxのper thread idをつかっていて邪道、という話になってますが、他のOSだと単にプロセスIDが丸ごとかわるだけなので、iiimf-skkが動作しないという事はないです。普通に~/.iiimf-skk/に設定ファイルを置くだけです。すくなくともhtt_serverはユーザ権限で動かしたほうが良いよ、という僕個人の主張もはいってはいますが。実際の所はこの部分はIIIMFという枠組みの中というより、各入力メソッドがもりもりやらなければならない部分で、IIIMFの最も弱いところであるという事実は謙虚にうけとめなければなりません。
他人のelispファイルを読み書きできないようなセキュリティはどうやって確保すれば良いのでしょうか?これもIIIMFがLE(IIIMF用の入力メソッドモジュール)にまるなげしている部分です。IIIMF自体には読み書きするためのAPIは全くないので、自前でなんとかしなくてはいけません。(この部分については後日に)
Q3. elispのプログラムを用いたDoSアタックで他のユーザが文字入力できなくなる可能性があるのが心配です。こういった事態はおそらくおきません。htt_serverは現状では、各socket毎にthreadを作成していて、それぞれ独立しているので、DoSアタックした結果(DoSアタックをした)自分自身が煮詰まることはあると思いますが。もしくは悪意のあるelispをなんとかしてインストールさせるといった方法かなぁ。どちらかというと、IIIMFのサーバ側というよりもXAUX等の補助ツールに対するDoSアタックの方が現実的には高いと思います。
--- kazehakase-0.1.3/src/actions/kz-actions.c 2004-02-25 21:56:18.000000000 +0900 +++ kazehakase-0.1.3.selection/src/actions/kz-actions.c 2004-03-05 19:05:48.000000000 +0900 @@ -273,6 +273,31 @@ kz_moz_embed_go_up(KZ_MOZ_EMBED(widget)); } +static void +act_search_by_selection (EggAction *action, KzWindow *kz) +{ + EggAction *entry; + GtkWidget *widget; + gchar *desc; + + g_return_if_fail (KZ_IS_WINDOW((kz))); + + entry = egg_action_group_get_action(kz->actions, "LocationEntry"); + + widget = KZ_WINDOW_CURRENT_PAGE(kz); + if (!KZ_IS_MOZ_EMBED(widget)) return; + + desc = kz_moz_embed_get_selection_string(KZ_MOZ_EMBED(widget)); + + if (!desc) + return; + + if (*desc) { + egg_entry_action_set_text (EGG_ENTRY_ACTION (entry), desc); + egg_action_activate(entry); + } + g_free (desc); +} static void act_go_location (EggAction *action, KzWindow *kz) @@ -1220,6 +1245,7 @@ {"FocusLocationEntry", N_("Move keyboard focus to location entry"), NULL, NULL, NULL, G_CALLBACK(act_focus_loc_ent), NULL}, {"ClearLocationEntry", N_("Clear location entry and move keyboard focus to location entry"), NULL, NULL, NULL, G_CALLBACK(act_clear_loc_ent), NULL}, + {"SearchBySelection", N_("Start querying by current selection string "), NULL, NULL, NULL, G_CALLBACK(act_search_by_selection), NULL}, {"OpenSelectedLinks", N_("Open selected links"), GTK_STOCK_OPEN, CTRL"G", NULL, G_CALLBACK(act_open_selected_links), NULL},
お会いするたびに繰り替えしてきた私の質問はfamaoさんが<br>「どうしていくのか?」です。
ありがとうございます。早速取り込みました。メチャ便利になりました。