GoogleのOpenSocialデベロッパー交流会に行ってきた

SNSAPIを統一するんだよねー、ぐらいのイメージしかなかったのだけど、やはり規格策定の現場の人の話を聞くとかなり明確に意図などが見えてきた。
OpenSocial APIでは大きく分けて3つのAPIからなっている

  1. 人や関係などを扱うPeople Data API
  2. 行動やイベントなどを扱うActivities Data API
  3. データのストア先である Persistentce Data API

現状、これらはJavaScript APIとして提供されており、アプリケーションもJavaScriptで記述することを前提としている。REST APIは仕様策定が進行中なので、もうすぐ使えるようになるとのことで、こちらができれば他サイトでSNSの情報を引っぱってきて利用するというのが簡単になってくるのだろう。
今のJavaScriptでの実装が先行しているのは、iGoogleなんかで使うGadgetの発展形として構想されたからなのだろう。サーバサイドの方が慣れた私にはなんでそんな迂遠なことをやっているのかなと思ったが、出自からすれば納得。
しかしサーバサイドで動くアプリケーションかJavaScriptで記述するアプリケーションかというのは、一長一短あって最後のフリートークのときに他社の人と話題になった。正直まだJavaScriptで大規模なアプリケーションを記述するには熟練したエンジニアが少ないこともあって、あまり現実的ではないと思う。サーバサイド実装での敷居はそもそもサーバを用意することだろうが、これもアプリを提供側のコントローラブルな環境で動作させることと裏表だしな。
Google gadgetが由来ということもあって、現在想定されているユースケースではかなりSNSサイトの中で閉じた使い方であるようだ。利用者、SNS提供者、アプリ開発者の三者がハッピーになる規格統一と言われていたけど、このままだとアプリ開発者にとってのメリットが薄いように感じた。
あとはOpenSocial対応のコンテナ実装としてShindigというのが既にあるとのこと。既存のSNSの仕組みと組み合わせればそれだけでGadgetの動作環境になりそう。そのままサービスに使うことはあまり無さそうだけど、この段階でリファレンスが有るというのは非常に便利かも。
次のセッションは外部の人を交えてのパネルディスカッション。講演者がサンプルアプリを披露していたのだけど、どれも短時間で実装できた事を強調されておりGadgetを作ったことのある人にとってはかなり開発がし易い環境であるらしい。SNS事業者の人が出てこなかったのは少し残念。
フリートークではGoogleの中の人を掴まえて質問してみたりしたが、日本人のエンジニアの人はOpenSocial専任に人ではないらしく突っこんだ質問はできなかった。逆に言うと専任でなくともサンプルのアプリをサクっと作れるということか。
また、たまたまgooの中の人と一緒になったのだが、この方がかなり切れる人のようで最新の動向など興味深い話が聞けた。今やOpenSocialのような半ば技術的な動向についてもフォローしておかないと、サイトの企画者としては失格だよね、とか。技術を理解する企画か、技術者自身が企画者にならざるを得ないのではないかな。