ウェブの原則とアーキテクチャ

ウェブのアーキテクチャという観点から、ウェブアプリのありようと、これからの方向性を議論してみた
1
@kis

@nsiena あ、Web SocketってHTTPのオーバーレイだと思ってました。違うんですね。すんません。としたらHTTPに関する部分前言撤回で、RPCはWeb Socketがいいですね。IEが対応してくれれば。

2010-01-06 00:08:35
@nsiena

@kis HTTP/1.1 で Upgrade: ヘッダで切り替えるようなプロトコルになってるですね。/ 一応 cf. The Web Socket protocol <http://bit.ly/7lJEJF >

2010-01-06 00:18:38
@kis

@nsiena ツールキットで自動的にweb socket対応ブラウザ・サーバーか判定して、可能ならweb socketでやりとりするような。

2010-01-06 00:29:20
@nsiena

HTTP と Web Sokect を併用。そのリソースモデリングは ROA 的に。HTTP でアクセス可能なリソースは公開 I/F のようなもの。必要十分かつ適切に定義すべき。Web Socket でアクセス可能なリソースは保護 I/F のようなもの。とみなすのは適切かしらん。

2010-01-06 00:27:29
@kis

@nsiena ぼくはブラウザ上のアプリケーションは今後GWTでしか書かないと決めたので、プロトコルはGWTまかせなのでよきに計らってくれるはず。このあたりの通信をプログラマが手書きできるレベルではなくなってくると思うので、ツールキットの役割がでかくなると思います

2010-01-06 00:27:23
@nsiena

@kis ですね。そういうふうに環境が充実していくのは重要な要因になっていくでしょね。ただ、リソースのモデリングは、まだまだ人間が意思決定しないといけないところだと思うので、やっぱり概念的理解は軽視できなろうなぁ、とも。→ 冒頭へループ ^^;

2010-01-06 00:31:24
@kis

@nsiena プロトコルはweb socketとして、クライアント自体はHTML+CSSではだめでしょうか?

2010-01-06 00:32:52
@nsiena

@kis ブラウザ表示用の表現は、とりあえずは HTML + CSS でいいんじゃないでしょかね。DELETE, PUT メソッドも HTML5 のフォームでサポートされるですし。/ すごく動的で JavaScript ではいまいちな場合は適当な RIA を作る、かしらん。

2010-01-06 00:44:13
@nsiena

あとは、リソースのモデリングをどうやるか。データモデリング的にやるか、ある程度の制約下でのオブジェクトモデリングでやるか、くらいしか思い付かない。それ以上の何かが必要なのかどうか。はて。情報設計とも絡んでくる。

2010-01-06 00:52:02
@kis

@nsiena ということで、Javaで書けるGWTが大本命だと思ってます。こんな感じ。 http://www.extjs.com/explorer/

2010-01-06 00:46:49
@nsiena

@kis GWT すごいねー。リッチな UI を作る機会があったら使って見ようと思ってるけど、ずっと保留しちゃてる ^^; 少し落ち着いたらいじりたいなぁ。

2010-01-06 00:58:07
@kis

@nsiena サーバー側と同じパッケージでソース書けるのでとてもいいです。あとは、さっきのExtGWTのほかにもSmartGWTとかUIツールキットがあってしのぎを削りそうなところとか。IDEも対応してきてるし「プログラムに適したプラットホーム」になってると思います。

2010-01-06 01:03:00
@nsiena

@kis ほうほう。やっぱり楽しそう ^^= 生成されるコードというか、C/S 間 I/F がどんなになるのか気になる。早くいじらなくては。と決意を新たに。/ いろいろとおもちゃが多くて大変だなぁ(←

2010-01-06 01:08:40
@nsiena

おっと、こんな時間。決意を新たにしたところで、しゃわっておやすもう。

2010-01-06 01:12:23
@kis

@nsiena サーバーとの通信は、こんな感じです。interface作ってサーバー側のimplとクライアントで呼び出しスタブになるasync作ります。

2010-01-06 01:13:29