アクセスカウンタが破壊：OpenSocialじゃ作れないの?

アクセスカウンタとして無料のアクセスカウンター！[動くアクセスカウンター]を利用していましたが、なぜかリセットされてしまいました。
カウンタの再生成をすれば事足りるのですが、またリセットされるのも何なので忍者カウンターにしました。
ついでに、Analytics導入時からのセッション数でカウンタをセットしたのでアクセス数がジャンプアップしています、あしからず。


ここからが本題。
OpenSocialの習作としてアクセスカウンタでも作ってみようとも思ったのですが、OpenSocial APIだけでは無理そうなのでちとハードルが高い。

OpenSocialには永続化の手段としてnewUpdatePersonAppDataRequest()がありますが、どうもこれはViewer別かつアプリ別かつOwner別の記憶領域のようです。
そして、更新権があるのはViewerのみ(コンテナによって違うらしいが、仕様上は)。

これでは、アクセスカウンタのようなViewer跨りのデータを管理するものや、GFCのコメント欄、5スター評価のようにアプリ跨りのデータを管理するものには利用できません。

このサイトでも導入しているEiji KitamuraさんのFriendConnect向けあしあとガジェットでは、VIEWERごとに自分のAppData領域にデータを保存する、という技。OWNERの友達のAppDataをまとめて取得という「テクニック」で何とか「みんなのあしあと」という「共有」データを演出しているようです。

しかし、この方法にも限界があり、メンバが増えるとサーバおよびクライアントの負荷が耐えられないような気がします。
また、単なるViewer毎のデータの集約ではない、本当の意味で更新可能な共有データを扱うことができません。

現状、Viewer間やアプリ間で共有・更新するデータを持つアプリを作成しようとすると、外部サーバを立ててgadgets.io.makeRequest() でやり取りを行うのが一般的かつ唯一の方法のようです。

Google Bloggerユーザのように自前サーバを持たない人もGoogle App Engine等を使えば良いようですが、こういった外部サーバを用意するのも一手間ですし、FriendConnectは残念ながらmakeRequest未対応 だったりします(2008.4.20追記:今は出来るそうです。出来るという記述を見つけていませんし、実験も出来ていません、念のため)ので、やはりOpenSocial APIだけで実現できることが望まれます。

newUpdatePersonAppDataRequest()の関数名の意味や、"Person"を特定するものと思われる第一引数に指定できるのが現在VIEWER IDのみという不自然な状況からして、OpenSocalも元々はより柔軟なデータ永続化を目論んでいるように思います。

who can read/write the data を仕様として決定すべきとの意見も出ているようですので、将来的にはより柔軟(でセキュア)なアクセスが可能になるかもしれません。