永井＠知能．九工大です．

Tcl/Tk プラグインをベースに，Tclet ならぬ Ruby/Tklet を検討中です．
課題は色々とあるわけですが，まずは安全な Tk の実行という点から
考えようとしています．
Ruby 側から Tcl/Tk 側の安全性検討を行い制限するのは困難ですから，
Tcl/Tk 側の安全性は Tcl/Tk 自体の safe-Tcl/safe-Tk に
依存するしかないでしょう．
つまり Ruby/Tk で安全なスレーブインタープリタを起動し，
その上で safe-Tk を有効にする (::safe::loadTk) という形です．
この場合の問題は，マスターインタープリタとスレーブインタープリタの制御，
および，Ruby との連携部分ということになります．
===============================================
・インタープリタの制御
  現在の tk.rb (と，そこから呼び出されるライブラリ) の作りは
  複数のスレーブインタープリタの制御ということを考えていません．
  かなりの手間をかけて，二つのインタープリタをコントロールできるように
  書き直すことは可能だとは思いますが，既存のスクリプト等まで
  書き直す必要が生じる可能性があります．
  また，Tk 側からのコールバックを受け付ける Ruby 側は一つですから，
  マスター／スレーブともに操作できるクラス作りをしていると
  マスターインタープリタの操作権を奪われる危険性もありそうです．
  そのため，現在考えているのは，スレーブインタープリタを生成したときに
  tk.rb で操作できるのはスレーブインタープリタだけとしてしまうことです．
  マスターインタープリタはスレーブ生成時のメソッド呼び出しの戻り値とされ，
  それを保存しておかない限りはマスターインタープリタの情報は失われます．
  で，マスターインタープリタを操作するためにはその情報が必要というわけです．
  問題は，

    (1) スレーブインタープリタからのコールバック時に
        マスターインタープリタの情報をどうやって隠すか．
        スクリプト作成者のミスで見えてしまうことがないようにしたいが，
        使い勝手も考えたとして，どうするのがよいか．

    (2) スレーブの起動後に，マスターが自身の管理下の widget を
        操作したくなったらどうするか．
        「それは不許可」ということにして問題がなければ話は簡単になるが，
        本当に問題はないか．

  というあたりです．これによって実装方針が変わってきます．

・スレーブインタープリタに組み込む ruby コマンドの権限
  Ruby との連携のためには，スレーブインタープリタにも ruby コマンドを
  組み込む必要がありますが，これにどの程度の権限を与えるか，
  実行許可の判断をどうするかが問題です．
  この問題は，次の汚染の問題とも密接に関わっています．

・Tk からの戻り値の汚染
  リソースデータベースを使う場合も同じ問題が関わってくるのですが，
  Ruby の safe-level を有効に使うには Tk から得られる値の汚染状態を
  考えねばなりません(従来は全く汚染されていない)．
  汚染設定ルールを考えてはみたのですが，「Tk から得られたすべての値は
  信用できない」ものとせざるを得ないのではないかと思えます．
  しかしながら，単純に「全部汚染！」としてしまうと
  既存のスクリプトの実行で問題がでる可能性もあります．
  対処策の検討ですが，

    (1) 全部汚染にしてしまっていい．
        それで問題が出るものは，もともと問題を抱えていたわけだから，
        問題がきちんと表面化してバンザイだ．
         → 反論 : 
              全部汚染にすると明らかに汚染されていないものまで
              汚染となって困ったことになるかも．
         → 反論への反論 : 
              リソース操作などで変更できる可能性がある以上，
              「明らかに汚染されていない」などはありえないのでは？

    (2) safe-level が 1 以上の時の結果は全部汚染にする．
        GUI 構築は level 0 で行い，eventloop 起動後は level 1 以上にする．
        eventloop を動かさない間はスクリプト内のデータだから，
        それは信用してもいいんじゃないの？
         → 反論 : 
              信用できないリソース情報を安易に使ってしまう恐れがある．
              それに，そういう意味合いなら次の(3)の対策でいいのでは？

    (3) eventloop を一度でも起動したら，以降は全部汚染とする．
        Tk を restart しても，Tcl に汚染されたデータが残っているかも
        しれないので，たとえ restart しても取消しはできない．
         → 反論 : 
              信用できないリソース情報の使用可能性という点はどうなった？

    (4) 「全部汚染」とするかどうかのモード設定メソッドを用意する．
        「どういう場合が」というのが決定困難なら，作者に判断を任せよう．
         → 反論 : 
              そういう判断ができるのなら，全部汚染でもいいはず．
              スクリプト作者は untaint するだけのことでは？

    (5) 「全部汚染」とはしない．
        全部汚染にするなど乱暴な方法ではなく，ちゃんと条件判断しよう．
         → 反論 : 
              それが簡単にできるくらいなら，問題にはなってない！

  といった具合です．
===============================================
これらの点について，いいアイディアはないでしょうか？
アイディアとまでは行かなくても，
単なる賛成／反対も含めて意見をいただけますと助かります．

# なお，Tcl/Tk 側の能力上，この機能のサポートは Tk8.0 以上となります．
-- 
                                         永井 秀利 （九工大 知能情報）
                                             nagai / ai.kyutech.ac.jp