RTViewの構成を変更
[youtube]http://www.youtube.com/watch?v=0xyjnU4zvtM[/youtube]
前回、試しに作ってみたものを修正。
前回は理解が浅いまま作っていたため、構成を再度検討。
その経過でXMPPなんてのも出てきた。
今回の動画はVirtualBox上のWindowsのみ。デュアルディスプレイを撮ると見づらいから・・・というだけ。
もう少し使えそうになったらまともな動画撮ります。
話は変わって・・・結果的に前回のコードの半分以上は書き直したと思う。
それだけではなく、構成が全然変わりました。
仕組みが分かってきたおかげで、使い易さ、リアルタイム性、スケールについてもちょっと考慮してみた。
使い易さについてはまだまだだが、CSSとJSの編集に対応しかけてる。
CSSの更新も判断出来るのだが、仕組みを検討中。
HTMLファイルの場合、クライアントからサーバーにHTMLをごっそり送ってしまえばいいのだが、CSSの情報はいったいどこに持つ？
CSSファイルは外部ファイルで読み込むようになってるから、そのファイルを書き換えないといけない。
安易に思いつくのはCSSもごっそりサーバーに送り、サーバーに保存する。
その後、それを参照するのだが、リアルタイム性はどうなんだ？
サーバーに保存するって、ローカルにあるファイルとの同期はどうする？
などなど、気になる点が多い。
今回もやっぱりIE(6と8。7は立ち上げてない)が動作せず。
動画の画像が表示されていないのはサーバーに画像がないから。
HTMLのURLも書き換えているため、サーバーに置いてない画像は表示されません。
CSSもJSも(ほぼ)そのファイルだけ更新するようにした。
だらだらと書いたので、前回からの変更をまとめると、
- 構成を大きく変更。理論上はWindowsからの通知も受け取れるはず。C#で書くか(動作確認はすぐ出来そう)。
- URLでファイルを指定できるようにした(前回はファイルの変更通知があって、それから表示してた)。
- CSS/JSファイルの更新を特定して変更(ただし、通知出来るだけで、ファイルの扱いについて考慮出来てないため変更は反映されない)。
こんな感じ。
大きくは3つだけか。意外と少ない変更だな。
仕組み的には面白く、今後使えるはずだから資料にまとめたいところ。
10Mbps程度の帯域で使うとどのくらいの速度になるのか気になる。
上りが遅い世の中だから、どうなるか。
HTTPよりは速いはずだけど、どの程度か不明。
こうなってくると、上りの速度も重要になってくるな。
目先の課題。
- CSSとJSの取扱い方。サーバー上に置くしかない気がする。memcachedみたいな感じにメモリ上でうまく動作させる？要調査。
- ファイル管理。ローカルとサーバーのファイルの同期と、マルチユーザで使用したときのコンフリクト対応。マルチユーザじゃないと楽なんだけどなぁ。今のところ、全く案無し。
- Windows用クライアント作成。プラットホームを選ばないAIRがいいのかな？C#の方が慣れてる分早く書けそう。
