TOKUNAGA Hiroyuki
tkng****@xem*****
2004年 6月 22日 (火) 14:08:33 JST
On Tue, 22 Jun 2004 00:00:31 +0900 YamaKen <yamak****@bp*****> wrote: > また、どなたか上記のメールを日本語に訳してくださると嬉しいです。 現実逃避に訳してみました -------------------------------------------------------- こんにちは。今日はuimとはなんであるかを明確にしてみたいと思います。 uimは便利なソフトウェアであるということは知られていますが、その哲学は よく知られてはいません。最近のuimとSCIMやIIIMF、immodule for Qtなどをめ ぐる状況を鑑み、我々は何が欲しいのかということを明確にするべきです。 以下はuimについての私の個人的な考えです。他のuimのデベロッパーはまた違 った考えを持っているでしょう。特に田畑さんはセキュリティに関してもっと深 く考えているはずです。 - デザイン哲学 * シンプルで効率が良いこと * あらゆる点でクリーンであれ * 重要でないことでは実用的であれ * 一般化のための一般化はやめたまえ * input methodの間の要求に対してシンプルさをキープしろ (超意訳：TSFみたいに異なったプログラミングモデルをシンプルにサポートできるべきである) - 長所 * バランスの取れた実用主義、開発中の緊密なクライアントの関係、 Schemeの柔軟さを生かし、迅速なscrap & buildができます（訳注：前半ちょっと意味不明） * (ここにセキュリティに関する考察が入ります) * アプリケーションやブリッジのプログラマに対して、簡単でシンプルなプロ グラミングモデルを提供します * Schemeを使った柔軟なプログラミングプラットフォームをバックエンド（ input method）プログラマに提供します * あまり計算機資源を要求しません * UNIX desktopやMac OS X、PDA、（もしかしたら）資源の少ない組込み環境、 携帯電話やゲームコンソールなど、幅広いプラットフォームをサポートします。 - 許容不可能な事 * 上記の長所を失うこと * (セキュリティに関する考察がここに入ります) - 許容可能な事 * uimを他のIMフレームワークに変換エンジンとして埋め込むこと。ただし、 セキュリティに関する配慮がきちんとなされているならば、という条件つき。 このやりかたは許容可能ではありますが、実装しても「代替的なブリッジ の実装」とみなされます。今のところ。 * ブリッジやアプレット、GUIといった非コアコンポーネントの廃止やマージ * 他のプロジェクトとの意味的なAPIの統一のためのClient APIの変更 ク ライアント（アプリケーション側）のプログラマに対し、統一されたプログラミ ングモデルを提供するため。 * クライアント側プログラムにおけるインプットメソッドサポート（CJKまで きちんとサポート）の普及のための他プロジェクトとの努力の統一（協力？） もう一回注意しておきますが、これはプロジェクトの総意ではなく私の個人的 な意見です。 「input methodの間」はMicrosoftのText Services Frameworkのような、もっ と一般的で現在のIMのモデルとは異なった技術のの仮定を意図しています。 SCIMのデベロッパーの方々へ。お互いに異見を交換しましょう。我々は次のス テップとしてSCIMの哲学を知りたいと思います。（もちろんscim ＠ fdoで。）私は 、我々が全てのインプットメソッド界の関係者にとってよいことをしているもの と信じています。 議論や質問はどんどんどうぞ。 -------------------------------------------------------- -- 徳永拓之 http://kodou.net/
