#361th PTT (in Japanese)

------------------------------------------------------------------
              第 360 回 PTT のお知らせ

     ---  Programming Tools and Techniques  ---
------------------------------------------------------------------
■日時: 2009年12月10日 (木) 18:30 から
■話者: 稲津 和磨 (電気通信大学)
■題目: サーバ/クライアント自動分割を備えたWebフレームワークの設計と実装
■概要:
近年GoogleMapsなどに代表される、Ajaxと呼ばれる手法を用いたWeb
アプリケーションが増加している。しかし、Ajaxを用いたWebアプリ
ケーションはサーバ側とクライアント側の両方のコードが協調して
動作し、それぞれの実装言語も異なっているためプログラミングが
非常に煩雑である。
そこで本研究ではWebアプリケーションを一つの言語で記述すること
で、開発効率を向上し、柔軟な処理の分割ができるようにすることを
目的とする。言語はJavaScriptを基本としたもので、提案機構はそれ
を読み込みサーバ側で動作するソースコードとクライアント側で動作
するソースコードを出力する。分割ポリシーを指定することで同じ
ソースコードから異なる分割方法を選ぶことができる。
本発表では研究の現状の実装の詳細について述べ、動作デモを行う。

■場所: 電気通信大学 西9号館 3F AVホール

  新宿駅より京王線，調布駅(特急・準特急で2つ目，15分) 北口下車，
  北西方向徒歩12分程度，電気通信大学西地区キャンパスの
  南西端にある白い建物; 甲州街道(国道20号線)
  下石原交差点の北20メートルに西門あり．

  交通ガイド
   http://www.uec.ac.jp/map/comm.html

  キャンパス内マップ(図中の40番の建物)
   http://www.uec.ac.jp/map/campus.html
------------------------------------------------------------------

質疑応答：

・分割のポリシーで速度重視の実行というのはサーバに実行させるということ？
場合によって異なる。負荷が集中しているサーバであればクライアントで実行した方が速度が早くなる場合もありうる。
それらは、どれがBestではなく状況に応じて切り替える必要がある。

・サーバの負荷が高まっているとかネットワークが遅いといった環境はどう扱うのか．
現状は提案機構の外から判断を行い、それに基づいて分割を行うことを考えている。

・JUMPはどういう動作をする？同期？コルーチン？
JUMPをした場合JUMP元は動作を止める、そしてJUMP先に制御が移り動作する。ある瞬間において、どちらか片方でしかプログラムは走っていない。そういう意味で同期している。

・JUMPを書かずに，変数の依存を解析して移動場所を決定できないか．
実際にやっている。
JUMPの書いてあるソースは変換後の物で利用者が記述するものではない。現在は利用されている変数を解析して、どちらの場所で実行するかを判断し、その境界に自動的にJUMPをはさんでいる。

・JUMP(L1)にhtmlは渡さなくていいのか？
無印の変数は自動的に共有されるつもりで記述したので、どちらかというとdatを一度TMPに受けている方が間違い。datに代入すればそれも共有される。という風に読んでほしい。

・サーバ側で作ったクロージャがクライアントで呼び出されるということはコンパイル時に分かりますか．
JavaScriptは動的な言語であるため、変数の中に何が入っているかは実行するまで分からないことが多い。おそらく分からない。

・assign式にクライアント側で実行するコードとサーバ側で実行するコードが混ざった時に、エラーにするのはもったいない．可能なら式を分割したりシリアライズして片方に移して計算すればどうか．
そのような実装にした場合、利用者が意図しないデータの共有が起き危険だと判断しエラーにしている。

・なぜanyにサーバの変数を代入した時にサーバ変数とならないか．
anyにサーバ変数を代入してしまうと、それ以降その変数に関する処理がどちらの側で行われるかは分からなくなる。
そのサーバ変数をそれ以降anyとして扱って良いと利用者が判断した場合は明示的にキャストを行う。( piyo = $S(s_hoge); など )

・文をまたがってサーバ、クライアントどちら側の変数にするべきかの解析は行わないのか．
行わない。本機構は文単位で実行場所を決定する。

・コンテキストは全て持ち回るのか．
場所に依存しないすべての環境を持ち回っている。
それによりオーバヘッドが生じるので、改善を検討している。

・通信コストよりも計算コストが安くても，各文は必ずサーバかクライアントの片方で計算して通信するのか．
はい。どちらか片方でのみ実行される。

・なぜリターンは呼び出されたのと同じ側でしかできないのか．
呼び出した側に場所に依存する情報が保存されているため。それを回収するためにreturn時には一度元の場所に戻る必要がある。

・スタックフレームは処理系が管理するのか．
はい。移動後に正常に動作するために本機構はスタックフレームも管理している。

・実コード化した中でクロージャを使われるとおかしな事が起こらないのか．
クロージャの転送は現状動作しない。

・セキュリティについてアイデアはありますか．
あまり考えていない。今後の課題とする。

・実行が終わった時にサーバ側のプログラムはどうなるのか
明示的にログアウトした場合はデータを破棄するが、それ以外の場合はセッションが切れるまではデータが残りつづける。

・「通信量をなるべく減らす」と「今の場所で実行を続ける」は必ずしも同じではないが、通信量を減らすポリシーについてアイデ
アはあるか．
すべての環境を送信するのではなく、一部を送信し、本当に必要になればそれをさらに送信する方式にすることで通信量は減らせるのではないかと考えている。

・サーバからクライアントに制御を移した後、サーバはクライアントから帰ってくるのを待って続きから実行すればプログラムカウンタを送らなくていいのではないか．
JavaScriptのブラウザでの実装がシングルスレッドになっているためそのようなことをするとブラウザのUIが固まる。

・実行中にポリシーを変えることはできないか．
理論的には可能。動的に負荷を計算することで動的なロードバランスをすることも出来ると思う。

・サーバとクライアント両方で同じコードを実行し早く終わったほうを採用することはできるか．
実際の運用でそれをすることは、どちらが早かったかを確認するのが遅くなりそうなので非現実的だが、あらかじめそのように実行をして分割の指針にすることは出来そう。

・ポリシーはどうやって指定するのか．
現状は3つのポリシーのうちどれかを指定するのみ

・変数名でクライアントとサーバを分けるというのは設計として良いのか．
難しい。名前からその情報を取り除く事は可能だが、それは設計は変わっていない。
場所を値と結びつけて管理するとまた別の設計になりうると思う。

・「統一言語」という名前は、サーバとクライアントのコードを同じ言語で書けるということと、一つのプログラムでサーバとクライアントの両方の挙動を書けるという二つのことを表わしているので考えたほうがよいのではないか．
その事象は包含関係あると思うので後者で十分だとは思うが、始めに前者のような関連研究（サーバサイドJavaScriptエンジン）を述べた後に本研究の話をしたほうが良かったかもしれない。

・積極的な最適化にも使えるのではないか．
動的に現在の情報を得ることで動作のパスを変えるなどの動的な最適化と、サーバクライアントにまたがった処理の最適化を行うだけの材料は示せると思う。実際にそれがこの研究で出来るかは今後の頑張り次第。