[ruby-dev:17108] Resource Database support on Ruby/Tk

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

このところ，Ruby/Tk でリソースデータベースを
有効に使えるようにしようと格闘しています．
どうすべきか悩んでいる点が少々ありますので，
いいアイディアがありましたら提供いただけると助かります．

まずは現状ですが，
=======================================================
・リソースデータベースにおけるアプリケーションクラスを
  設定できることは確認した．
  また，同時に root widget を特定の Window ID を持つウィンドウに
  埋め込むことができることも確認した．
  ただし，これら設定は Tk の初期化時点で行う必要があるため，
  require 'tk' の後に Tk.restart(name, use) のように
  パラメータを与えて Tk を再起動するという形でサポートすることとした．
  これにより，Tk.restart('xxx') などとすれば，
  ------------------------------
  Xxx*Button.foreground: yellow
  ------------------------------
  というようなリソース設定が使えるようになる．
  なお，この場合，アプリケーション名も 'xxx' となる
  (複数動かしている場合は 'xxx #2' などとなるので注意)．

・リソースデータベース上での名前を同定するために，
  ウィジェット生成時に名前を widgetname 属性で指定できるように作業中
  (フレームウィジェットでのリソースクラスは，以前から設定可能)．
  この際，ついでに，「親を生成時の parent 属性で指定できるようにする」や
  「属性名等をシンボルでも指定できるようにする」も実装している
  (当然，parent 属性が有効なのは widget 生成時のみ)．
  例えば，
  ------------------------------
  f = TkFrame.new(:classname => 'Bar').pack # 'classname' => :Bar も可
  b = TkButton.new(
        :parent     => f, 
        :widgetname => 'quit', 
        :text       => 'Quit', 
        :command    => proc{exit}
      ).pack(
        :pady   => 3,    # 'pady' => 3   も可
        :fill   => :x    # 'fill' => 'x' も可
      )
  ------------------------------
  などという記述も可能となる．
  先のアプリケーションクラス設定と合わせると，このケースでは，
  ------------------------------
  Xxx*Bar.Button.foreground: red
  Xxx*Bar.quit.text: 終了
  ------------------------------
  といったリソース設定が可能となる．

・ボタンなどのコマンド属性もリソース指定可能．  ( ※ 問題点１ )
  Tcl/Tk インタープリタ側に定義された ruby コマンドを用いることで，例えば，
  ------------------------------
  Xxx*Bar.quit.command: ruby {print "bye...\n"; exit}
  ------------------------------
  などと設定することができる．
  ruby コマンドの引数として渡される Ruby スクリプトの文字列は，
  Ruby のトップレベル (main) で評価される．

・ユーザによる手続き定義をリソースで指定できるように作業中．  ( ※ 問題点２ )

=======================================================

問題点１は，セキュリティに関するものです．
Ruby のトップレベルから実行可能なものは，
ユーザによってすべて実行できてしまいます．
しかも，仕組み上，これを不可能にすることはできません．
ですが，command 属性を持つメソッドにおいて，
command 属性を設定しないということは稀でしょう．
属性値を設定した場合にはリソース設定の値は使われませんから，
現実には，これ単独では，問題になることは少ないと思います．
ただし，command 属性を定義しないままにしておくと
危険であるということは頭に置いておかねばならないでしょう．
もちろん，必要とあればリソース設定を使うのは構いませんが，
チェックの責任はアプリケーション作成者に委ねられます．
button['command'] でリソース設定されている文字列を
獲得することができますから，その文字列をチェックした上で 
command 属性を再定義するという形式でもいいのかもしれません．

問題点２が，実装方法等で迷っている部分です．
アプリケーションのカスタマイズを許すのであれば，
ユーザ定義の手続きを組み入れて使えるようにした方が
自由度が上がっていいのではないかと思います．
ですが，これはセキュリティ上の危険と隣り合わせです．

実現するためのポイントとしては，
--------------------------------------------------
・定義したいの手続きは widget の属性には存在しないものである．
  したがって，定義の読み出しはスクリプトで行わねばならない．

・リソース設定を読み出すためには，対象となる widget が必要である．

・定義された手続きをユーザ手続きから利用するためには，
  トップレベルのメソッドとして定義するか，レシーバが見えている必要がある．
  しかもそれは，リソース設定との対応付けが明確であるべきである．
  その意味では，トップレベルのメソッドとして定義するのは
  メソッド名称の制約が大きくなり，あまり望ましくはない．

・自由な設定を許すとセキュリティ上の危険が大きくなるので，
  制約を課すことができるようにすべき．
  また，制約はコントロールできる方が望ましい．
--------------------------------------------------
というようなところかと思います．

色々と考えていたのですが，
今のところは次のような形式で実装しようかと考えています．
--------------------------------------------------
・TkOption モジュールに gen_proc_class メソッドを定義．
  これは，リソースクラス名，親リソースクラス，メソッド名リスト，
  メソッド追加の是非，セキュリティレベルをパラメータとして受け取り，
  TkOption モジュール内にリソースクラスを定義するようなメソッドとする．

・TkOption モジュール内に，リソースクラスの雛形となるクラスを定義する．
  new は private class method とし，オブジェクト生成を許さないようにする．
  各リソースクラスは，これを親クラスとする．

・親リソースクラスが指定されなかった場合は TkOption モジュール下に，
  指定された場合はその親リソースクラス下に，新しいクラスを作成する．
  これにより，例えば '*Foo.Bar.method: {|x, y| x + y}' という定義に対し，
  TkOption::Foo::Bar.method(x,y) という呼び出しを可能とする．

・リソース設定を読み出すために，リソースクラス名をクラス名として設定した
  フレームウィジェットを生成し，保持する．
  このフレームウィジェットは，画面上には配置しない．

・リソースで定義することができるメソッド名をメソッド名リストで与える．
  リソースクラスを定義する際に，これらのメソッド名を利用して
  リソース設定を読み出し，文字列から手続きオブジェクトを生成し，
  クラスメソッドとして呼び出せるようにする．
  実装は，メソッド名をキー，手続きオブジェクトを値とする Hash で管理し，
  method_missing を利用して手続きを call する方法を取る．

・メソッド追加を許可する場合，未定義メソッドがはじめて呼び出されたときに
  リソースデータベースを検索し，設定を追加するものとする．

・セキュリティレベルは，そのリソースクラスで定義されるメソッドの
  実行時のセキュリティレベルのことである．
  Hash で管理された手続きオブジェクトを呼び出す際に，
    Thread.new{
      $SAFE = セキュリティレベル
      手続き.call(*args)
    }.value
  とすることで，外部定義の手続きを指定されたレベルで実行するようにする．
--------------------------------------------------
こんなところですが，もっと良いプランがあるんじゃないかと思います．
ぜひご意見をお願いします．
-- 
                                         永井 秀利 （九工大 知能情報）
                                             [e-mail]