RTViewの構成を変更

Ken published on
5 min, 936 words

Categories: 未分類

前回、試しに作ってみたものを修正。 前回は理解が浅いまま作っていたため、構成を再度検討。 その経過で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#の方が慣れてる分早く書けそう。