websocketsのpipeline « kumama
# ちなみにHTML5のドラフト上、「websocket」ではなく「websockets」が正解・・・だったと思うw
おっと、本当にwebsocketsだった。(^^;
それはさておき。
websocketsの利用シーンとしては現状httpでは出来ないサーバ側からの通知とか、
非同期通信ばかりを思い浮かべていたけど、ajaxで出来る事もwebsockets化する！って
言うのはなんと言うか着眼点が面白いというかちょっと思いつかなかったなぁと言う感じ。
FileAPIとXHRを使ってファイルをアップロードするサンプルを作ってみたわけですが、
風の散歩道のような写真アルバムページとか、回転テーブルのようなページを作る為の管理画面にするつもりでした。
流れとしては、
- HDDのファイルを読み込んで、
- canvasで確認し、
- リサイズなどの処理を施してファイルサイズを小さくしてから、
- サーバーに送信する。
と言う物。
今までだと、ファイルが大きなまま送信して、ImageMagickなどでリサイズする必要がありましたけど、
これがまた、サーバーの負担が大きいのなんの。
1200万画素のカメラで撮影したものは５MBを超えるわけで。
当然何枚も画像をアップロードすることになるわけで、XHRとか<form>でアップロードしても、multipart/form-dataというちょっと特殊な形式で送信しないと行けないので、この分割処理もバカにできないんですよね。
そういうときにもwebsocketを使って、send()１回に１つのファイルを送信すれば、分割処理は完全になくせると思います。
とはいえ、
「通信開始直前に接続 -> しばらく通信する必要がなさそうなら（ページを開いたままでも）接続解除」
というような行儀の良いアプリならともかく、
「ページを開くと同時に接続開始、ページを閉じるまでつなぎっぱなし」
だったら、サーバーのネットワークリソースやメモリリソースが無駄に使われると思いますし、
果たして行儀の良いプログラマーしかいないのだろうか、というと、たぶん無理でしょう。
ですから、個人向けホスティングサービスならwebsocketはサポートしないだろうなと思います。
http(s)なら今までの資産として、javascriptのライブラリも使えるし、
cookieとか認証とか文字コード変換とかjsonとかproxyでのキャッシュとか
今まで蓄積してきたモノが使えます。
プロクシは、、、
プロクシサーバーを有効に使えないデータのやりとりが主だと思うので、xhrでもformでもあまり関係ないと思います。
XMLとかJSON、CSVといったデータフォーマットは、基本は生のテキスト/バイナリデータだから、たぶん既存の物のままでもいいはず。
JavaScriptの負担が増えるのは、
最初の接続の時にdocument.cookieから取り出して、自分でデータを送信しないと行けない、
XMLのテキストデータをXMLオブジェクトに変換する作業が必要
なくらいじゃないでしょうか。
cookieの処理がクライアント任せになるので、逆にサーバー側は、セッションの管理が不要になると思います。
