クライアントだけでマッシュアップすること
これは、ちょっとid:kazuhookuさんと意見が違って、かなりあるのではないかと思っている。悲しいかな具体的な例があまりでてこないので単なる主張だけど。
データを組み合わせるのであればサーバサイドでいろいろな演算を行いたいだろうと思うし、そこをあえて、可能性が限定されるクライアントサイドで行う必然性があるユーセージモデルが自分には見えません。
http://d.hatena.ne.jp/kazuhooku/20071207/1197028716まずサーバサイドでできることとクライアントサイドでできることと比べたとき、あきらかにサーバサイドで出来ることの方が多いというのはもちろん同意するけれども、それほど致命的でなくなっているようなケースもあるように思う。
を読んで。
クライアントサイドでデータのマッシュアップをやりたい理由について自分の思うところを。
まず前提として、データのマッシュアップを目的として作業をするひとを想定しています。データのマッシュアップをしたいけれど、ブラウザのデフォルト状態でできないことはしない、というユーザは想定していません。
ひとつめ
サーバで全てを計算するのだと、統計のパーソナライズ処理に限界がある。一人のユーザしか見ないデータを計算することはコスト的に見合わない。けれど、高性能なクライアント上でその計算をやってくれるなら、ユーザ一人一人に対して細かい統計処理を行うことができる。
だからクライアントサイドでよりパーソナライズされたデータのマッシュアップをやりたい。
現在はFirefox extensionまたはGoogle Gearsを導入することでsqliteを使ってサーバと同程度にデータのマッシュアップができる。
ふたつめ
データとDBがローカルにあるのなら、ローカルで処理したほうが安定性、信頼性、応答性全てがサーバで処理されるよりも優れている。
みっつめ
トレンドとして。
一般ユーザを対象にした、サーバでマッシュアップをするツールを提供するのは、ビジネスとしてうまくいかないという結論になりつつあり、エンタープライズ向けのマッシュアップにシフトしてきているらしい。(» A bumper crop of new mashup platforms | Enterprise Web 2.0 | ZDNet.com)
BEAがGreasemonkeyの記事 Peter Laird's Blog: O'Reilly Safari + BEA dev2dev + Greasemonkey = Web Mashup をpostしていたり、Greaesemonkeyとセットでマッシュアッププラットフォームとして大きな力を発揮するGoogle GearsもOracleやSalesforceから問い合わせをうけていたり(Google開発者懇談会で聞いたはなし)。
エンタープライズ向けという前提があるのならクライアント側でマッシュアップをするのには制約が多いというのは(そこまで)当てはまらない。自社外のサーバになんらかのデータを渡す必要がある、という不安もない。
拡張機能を入れることでサーバサイドでしかできなかった処理の一部をクライアントサイドでもできるようになってきているので(そしてクライアントサイドのCPU/IOには余裕がある)、クライアントサイドでデータのマッシュアップをすることを考えてもよいのではないかと思い
ます。
もちろんクライアントサイドではやりにくいこと(定期的なページのクロールなど)もあるので、クライアントサイドでできないことをサーバで行い、クライアントサイドでやるのが合理的なものはクライアントサイドでやるのは、アプリケーションによっては十分現実的なことだと思います。
