HTML5でローカルストレージが持てたり、画像描画ができるようになり、また、JavaScriptもだいぶ速くなってきたので、ブラウザ上でスタンドアローンのアプリケーションが組めるようになりました。
でも、そうすると、足りない機能が出てきます。
それは、Webアプリケーション間の連系です。
たとえばブログ上にFlashファイルを埋め込みつつ、けどFlashプレイヤーがなくても見れるようにしたいという場合、ブログサービス提供側がなにか仕組みを用意して、HTML5に変換して表示するという仕組みが必要になります。その場合、Flashプレイヤーをインストールしてある環境でも、HTML5に変換されたものを見るということになります。
ファイル形式だけ指定すれば、あとはユーザー側でアプリケーションやサービスを選択して、表示を行うという仕組みが欲しくなります。
あるファイルをクリックしたときに、ブラウザで対応できなければ「保存」か「アプリケーションで開く」のメニューが表示されますが、同じ仕組みでここに「サイトで開く」というメニューも出るようになって、サイトを登録しておけば自動的にそのファイル形式はそのサイトを使って表示するということも可能になります。
そして、Webアプリケーションの連携として最も欲しいものは、たとえば、Google Docsのスプレッドシートに描画サービスCacooの図を貼付け、その図をダブルクリックしたら、Cacoo上で編集ができるといったことです。
もちろん、Cacooが表示用と編集用のURLを設け、Google Docsがそれに対応する仕組みを組み込めば可能です。でも、新しいサービスを作ったとき、それをいちいちGoogle Docsに対応してもらったり、逆に新しいサービスをいちいち自分のサイトで対応することは不可能です。
また、そのときの図形データをGoogle Docs上に持てるようにもしたいです。
これができるというのはどういうことかというと、つまりWebアプリケーション間でのドラッグドロップや、コピーペーストができるようになるということです。
ついでに、デスクトップのファイルとWebアプリケーションの間でドラッグドロップする仕組みも欲しいです。
ようするに、WindowsのOLEオートメーションをWebアプリケーションでもやる必要が出てくるということです。
リンクするだけなら、かなり簡単に仕組みを作ることができますが、問題は認証です。
表示の場合には、ブラウザからそれぞれのサイトの認証を行えばいいのですが、たとえば年賀状送付サービスで年賀状のデザインにcacooの図を貼り付けた場合、年賀状送付サービスやさんでの印刷時には年賀状サイトからcacooのほうに認証を行う必要がでてきます。
Open IDやOAuthの発展形が求められるのだと思います。
HTMLはドキュメントのリンクを提供しました。
HTML5でアプリケーションが作れるようになったら、こんどはアプリケーションのリンクが必要になると思います。
恐らくHTML6ではこのようなことが議論されるようになるんではないでしょうか。
ついでにその先を考えると、恐らく通信頻度を減らすための仕組みが議論されると思います。
HTML7だけではなく、HTTP・TCP/IPまで含めた議論になるとは思いますが、通信量ではなく通信頻度が問題になってくると思うので、たとえばひとつのイベント会場や学校から1000人がそれぞれで1分に一回twitter.comに接続するというのを、イベント会場単位・学校単位でまとめて通信するような仕組みが必要になってくるように思います。
今はまったくそういった必要性はなく、それが必要になる状況を想像することも難しいですが、増え続ける通信量を考えると、どこかのタイミングで世界規模で通信量を下げる取り組みが必要になってくるように思います。もっといえば、通信にかかるトータルの電力量を抑える必要性です。
たとえば、産総研の資料では、2020年ごろにルーターの消費電力が2005年の総発電量に匹敵するようになるという話もあります。
http://www.aist.go.jp/aist_j/press_release/pr2008/pr20081001/pr20081001.html
それぞれのサイトが機能や性能の向上だけを考えればいいという時代が終わるときは必ず来て、利便性を損なわずにいかに世界全体の通信量・通信のための電力量を落とすかということを考えないといけなくなるんだろうと思います。
