[Anthy-dev 2091] 今後の開発方針

Back to archive index

YamaKen yamak****@bp*****
2005年 6月 6日 (月) 11:03:15 JST


ヤマケンです。

もう2ヶ月ほどcommitしてない状態を続けてしまっていますが、先日徳
永さんと太田さんに会って今後の私のuimへの関わり方について相談し
てきました。

結論から言うと、forkや脱退は無しです。真剣にforkを考えたのはこれ
で2度目ですが、何とか妥協点を見つけてもらえました。わがまま言っ
てすいません。他のcommitterの皆さんにはまだ了解を頂いてませんが、
何か思うところがあれば遠慮なく言ってください。


私の考えとして以下のような事を話しました。

・私と他のcommitterとの間での目標や開発スタイルの違いから、お互
  いにやりたい事の足枷になってしまっているんじゃないか

・正直、プロジェクト内外の人々と議論する気力が尽きてきた。一々説
  明して理解を求めるよりも、その分の時間で自分が正しいと思うコー
  ドを書いて、それと指向が合わない人とは別々に作業した方がお互い
  幸せなのでは

・デスクトップ分野には実用的なSCIM用日本語IMが出てきたし、アプリ
  ケーションとIMのインタフェイスも昔に比べて改善されてきたので、
  そういった使命から解放されてもっと冒険したい

・現在のuimは当初の設計の範囲を超えて拡張されているので、あちこ
  ち無理が出ている。段階的な整理を進めてきたが、互換性への配慮が
  負担になってきた(例: lazy loading導入に伴うim-registerや.uimの
  意味の変化、基盤コード変更への各IMの追従)

・ある程度広く使われて実用性を期待されているので一時的な退行や実
  験が行い難い(例: リソース消費を度外視したScheme実装の差し替え)


色々相談した結果、以下の3点の問題について解決もしくは妥協を見ま
した。

1. R5RSにほぼ準拠し、SRFI-1の全ての機能が使えるScheme実装を標準
   にしたい

   現在はSiodのR5RS互換性改修やSRFI-1関数の実装・テストに結構時
   間を取られているし、R5RSを前提に書かれたコードをuimに取り込む
   のも難しい。一時的に省メモリ性を切り捨てて他の実装に鞍替えし
   てしまえばuim本体の開発に集中できる。十分成熟した後で省メモリ
   性を取り戻せばよい。

2. 互換性の切り捨て

   ブリッジとのインタフェイスを安易に変更する事は避けるべきだが、
   それ以外の部分で旧仕様を維持するのは開発を妨げるし、やる気を
   削ぐ元になるので、小まめに変更してしまいたい。

3. ある程度の隔離

   - アプリケーション側のインタフェイスを適切に保つ事については
     多くの方々の努力により軌道に乗っているようなので(immodule等)、
     当分手を引きたい。他のIMフレームワークとの仕様共有といった
     話題も同様

   - Linux文化やデスクトップ環境から生じる要求や問題等とはちょっ
     と距離を置きたい。元々入力効率が主な興味なので

   - 周囲の状況に縛られずに必要な実験的コードを導入したい(リソー
     ス消費を度外視したコード変更等)

1.の作業については、リソース消費に配慮しつつという条件込みで太田
さんが実現を引き受けてくれました。実現時期はまだ明確ではないです
が、アテができたのでそれまでの間はSiodで耐えようと思います。

2.については、そうだねそうしましょうという話になりました。

3.は、やる気を保って開発を進める事が重要なので、その障害になるな
ら活動の縮小は仕方ないという結論になったと記憶しています。勝手な
言い分で申し訳ないんですが。また、実験的なコードについては
yamakenブランチとして半分派生プロジェクトのように気が済むように
やって、成果が出たら皆でがんばってマージしようというありがたい言
葉を徳永さんから頂きました。これでだいぶ気が楽になりました。感謝
します。

「やる気は有限なリソース」とは徳永さんの言ですが、気をつけたつも
りでもちょっと濫用が過ぎたようです。徳永さんには負担をかけっぱな
しですいません。もうしばらくして余裕が出てきたら無理のない程度に
はお手伝いしたいと思います。

誤解の無いように言っておきますが、皆で寄ってたかってコードを書き
まくってしまうuimプロジェクトの体制とメンバのノリは大好きです。


今後の開発予定は以下のように考えています。

・デスクトップ分野については徳永さんがまだ色々やりたい事があるそ
  うなので、私はあまりクチバシを突っ込まず必要に応じてお手伝いす
  るに留めたいと思います。他の方がやりたい事についても同様です。
  私は基本的にscm/とuim/以下のコードに専念しようと思います

・composer branchの成果はtrunkにマージしたいと思っています。ただ
  し、rkの置き換えであるevmapへは一気に移行はせず、当初はanthy 
  だけで利用したいと思います。当然IMにより変換テーブルやキーバイ
  ンドの書き方が変わる等の混乱が発生しますが、uim-prefだけを使っ
  て設定を行う人には見えない事なので、これがuimクオリティという
  事でご容赦頂きたいと思います

・uim 0.4.6でscm/Makefileで行っているIM登録処理が問題になり、uim 
  側で細分化パッケージングを補助するスクリプトの提供を約束しまし
  たが、私の作業においてはやっぱり責任範囲を縮小してuim全体を1つ
  の単位としてas-isで提供するに留めさせて頂きたいと思います。bug 
  扱いはご勘弁ください。もちろんどなたかがコードを書いてくださる
  のは歓迎します


私のわがままにより皆さんにはご迷惑をおかけしますが、最も書きたい
コードをどんどん書く事が一番の貢献になると信じて、欲望の追求に努
めたいと思います。

-------------------------------
ヤマケン yamak****@bp*****



Anthy-dev メーリングリストの案内
Back to archive index