[dennou-ruby:002664] Re: スクリ プト検査

["GOTO Kentaro" <gotoken@xxxxxxxxx>]

06/07/11 に Takeshi Horinouchi<horinout@xxxxxxxxxxxxxxxxxx> さんは書きました:
> > END問題は、
> > プロセスを分て、結果は何らかの方法で通信するとかすればよいのかな？
>
> いずれにしてもプロセス（or 最低限スレッド）をわけることは必要と思
> います。これを書かなかったので、余計混乱を招いてしまったように
> 思います。

いや、それは前提にしても難しさはあまり変わらないとおもいます。
本質はリモートコードの実行ですから、メソッド呼び出し以外の
操作を認めるかどうかというのが根本的な問題だとおもいます。
より詳しく言うとブロックをみとめるかということです。
ブロックを許すと検討すべき事項がどかんと広がります。

ブロックを持たないメソッド呼びだしに限ったとしたら、
コードを受け取るインターフェイスは実装が面倒すぎる場合があるとおもいます。
メソッドはレシーバとメソッドと引数が与えられれば十分ですから、
これらを指示できる UI を状況に応じて最低限用意するのが
現実的ではないでしょうか。

> GPhys は、内部ではいろんなクラスを使ってますから、例えばFile
> クラスは禁止となると走りません。そこで、ユーザーが与えた
> スクリプトは、なんらか隔離された状況で走る必要があるでしょう。

そしてメソッド呼び出しに限ったとしても汚染モデルのようなものを
改めて設計する必要がありそうです。
なにに由来するものはなにをして良いのか。

> 例えばdruby で交信しながらとか。しかし、よく考えると GPhys で
> もなんでも、リモートオブジェクトは全部 DRbObject になるので、
> クラスで制限というは破綻しますね。druby を使うなら、開発要素は
> ゼロに近くて楽なのですが、webサービスだと大変でしょうか。。。
> なお、

druby をつかうというのはブロックの実行を認めることですから、
メソッド呼び出し以外の任意のコードを検討する必要があります。
ともかく druby は十分に信頼できるノード間で使う前提で設計されているので、
そうでない相手に対して使うべきではありません。

> >>> 自分たちで出来る解としては機能はwebサービスで提供して
> >>> クライアントサイドに対してそのサービス用の ruby バインディングを
> >>> 用意するというのがひとつの落としどころのような気がします。
>
> と同じようなことのつもりです。ただ、ブラウザー上で動くという。
> 技術的には web サービスでないといけないのか良くわかりませんが。

webサービスにするのが良い理由は、XMLHttpRequest を使えるからです。
それ以上の理由はありません。もちろん XMLHttpRequest を使うというだけなら
webサービスにしなくても通常のフォーム由来のPOSTを受け取る
CGIでも良いです。

ステージとして、
(1) w3m で使える程度の HTML しか吐かないレベル(IMGはあり)
(2) 機能が固まったら、Javascript を使ってカッコよく置き換え
(3) HTTPインターフェイスが決まったら web サービス化しながら
   web サービスを呼び出すライブラリの作成

みたいな感じだと途中の段階でも遊べてよいかなとおもいます。


> > gphys(or gphysの配列)をうけて、結果のgphysを返すと考えていました。
> > 実装方法や、やりたいことによって変るとは思いますが。
>
> はい、そのつもりですが、問題はどう（どこから）受け取って
> どう（どこへ）返すか考える必要があるかと思います。
> 「どこへ」問題については、選択された GPhys 相当のものが
> ブラウザーに並んで表示されているのであれば、そこに加え
> ることが出来て欲しいですね。「どう」やってといえば、
> メソッドの戻り値が GPhys だったらというのが一法ですが、
> メソッドでなくメインで対話的に作業していきながら、
> 可視化してみたいのを add_to_cart(a_gphys) 的なメソッド
> でプッシュするのも考えられると思います。

たとえばリンクアンカーとかアイコンで GPhys オブジェクトをあらわして、
通常のデスクトップアプリを模したメニューとダイアログで操作を進めるものを
提供するというのが現実的かなとおもいます。
数値や文字列は、スライドバーとか text input フォームでよいですし。
グルーピングはチェックボックスで。

> > たいていの解析が出来るというのは結構野望っぽいですが、
> > 西澤さんがこれまで gtk で書いたようなツールを
> > ウェブアプリケーションにするのが最初のゴールなんじゃないかな
> > と思っていました。
>
> はい、全くその通りです。今はその先の野望の話に飛んでましたが、
> そっちをちゃんと考えないと、ですね。

僕がとんちんかんなことをいっているのではないことがわかってよかったです :-)


ごとけん