I developed FriendIntroducer as an experiment and was trying to understand how FriendConnect is different from ordinaly OpenSocial implementation. So this time, I’ve tried to develop a gadget which you can find FriendConnect interesting, Footprints. You know the idea if you’ve tried MyBlogLog before.

What is Footprints?

Footprints is a gadget to track visitor of you blog. Look at the gadget on bottom left of this blog. If you’re not joined or signed in, do it to check what it does.

Footprint is a pretty popular idea on japanese social networks. Once upon a time, SNS were all closed and it was difficult to find people you may know. Footprint functionality was a good tool at that time to find who’s interested in you.

As you could imagine, this gadget records visitor and its time. When viewed by others, timestamp will be displayed how long ago, you’ve visited. Also, you can remove your own footprint if you want. The xml is located at:

http://devlab.agektmr.com/OpenSocial/FriendConnect/Footprints.xml

Feel free to take it and use it on your blog.

本日米Yahoo!から、Yahoo! Open Strategy 1.0として、ディベロッパ向けにYahoo! Application Platform (YAP), Yahoo! Social Platform (YSP), Yahoo! Query Language (YQL)がリリースされました。

Yahoo! Social Platform

プロフィールやアドレス帳、更新情報等、ソーシャルにまつわるAPIをRESTベースで提供するものです。認証機構にはOAuthを利用し、PHP版、Flash版のライブラリも提供されていますが、このREST APIはOpenSocial互換ではありません。

Yahoo! Query Language

SQLライクなコマンドを送信する事でYahoo! Pipesのようにデータ取得が可能なウェブベースのAPI。FacebookのFQLのようなもののようです。

Yahoo! Application Platform

Yahoo!上で動作する埋め込み型のアプリケーション。OpenSocialのガジェットプラットフォームは現時点ではサポートされていませんが、JavaScript APIは使えるようです。大きく2つのビューがあります。

Small View

HTMLまたはYML Liteのみサポート。JavaScriptはサポートされていません。YMLは、Facebookで言うところのFBMLのようなもので、 My!Yahoo等様々なページにパーツとして表示する事が想定されています。

Canvas View

ディベロッパが指定したURLが出力したYMLをプロキシして表示するタイプのアプリケーション。Facebookライクな仕組みですね。もちろん、サーバーサイドでYahoo! Social Platformを使ったプログラムを書く事で、OAuthで認証を行い、RESTベースでソーシャルグラフを取得したり、コンタクトリストを取得したりすることできます。

また、OpenSocial JavaScript API(v0.8)にも対応しているので、クライアントサイドから更新情報を追加するといった利用も可能な様子。Cajaが利用されているので、セキュリティに気遣う事なく実装できそうです。(いつのまに実用レベルに達していたのでしょうか・・・)

時間のある時にでもサンプルアプリケーションを作ってみたいと思います。

所感

今回のYahoo!のリリースは、FacebookプラットフォームとOpenSocialのいいとこ取りといった感じ。ただし、OpenSocialに完全に準拠している訳ではないので、他で作ったアプリケーションをちょっとだけ書き換えて転用、という訳には行かなそうです。

例えば、クライアントからmakeRequestを使って外部サーバーのデータを取得するようなJavaScript APIは利用する事ができません。また、OpenSocialならHTMLを出力すればよかったものが、YMLを出力しなければなりません。等々・・(追記：Gadgets Core APIは利用できるようです。ただし、Pref、Viewなど、featureで指定する機能は利用できません。また、YMLは通常のHTMLに加え、独自タグを使って拡張した機能が使える、というもののようです。ただ、Caja対応のために外部スクリプトを読み込めないことが、他のコンテナに実装したガジェットをインポートする際の障壁になりそうです。)

ただ、世界最大のポータルサイトがOpenSocialに対応することの意義は大きく、今後の動きは要注目です。全体の戦略からすれば、OpenSocialの対応はあくまでパーツに過ぎず、今後のウェブのあり方を位置づける重要な意味を持ちます。先日行われたYahoo! Open Hack Dayのプレゼンテーションは必見です。

どんどんプラットフォーム化していくウェブと、その中で占めるソーシャル機能の持つ重要性が、日本でも認識される日はそう遠くないと思います。

前エントリでの予告通り、実際にサーバーサイドでコードを書き、MySpaceのData Availabilityを使ってOAuthを試してみます。Data Availabilityという名前は大げさに聞こえるかもしれませんが、実際はOpenSocial RESTful APIです。ちなみにData AvailabilityではまだJSON形式のみのサポートで、AtomPubには対応していません(しかも404が返ってくる。これに相当ハマった○|￣|＿)。

今回はOAuthを使って認証・認可を取得し、Data Availability APIを叩くところまでを解説します。

下準備

まずはサンドボックス環境にMySpaceにアプリを作ってください。細かい手順が分からない方はこの辺を参考にしてください。

MySpaceではガジェットアプリも外部アプリも同じように扱われるようです。

Edit Detailsを開くと、アプリケーションの詳細設定を編集することができます。

ここでOAuthの利用に必要なものを思い出してください。まずはコンシューマキー(consumer_key)とコンシューマシークレット(consumer_secret)です。

MySpaceの場合、アプリケーションを登録した段階でこれら2つが発行されます。コンシューマキーについては好きなものに変更できますが、ここではアプリケーションのガジェットXMLぽいURLにしてみました。後で必要になりますので、どこかにコピペっておきましょう。

次に、同じページの下の方にExternal Site Settingsという項目があります。これがData Availabilityの肝です。

• Use External Domainにチェックを入れる
• External URLにMySpaceからの誘導先URLを入力
• External Domainに実際に外部アプリを置くサーバーのドメインを入力
• 利用規約を読んで同意

これで準備オッケー。

OAuthを実装する

今回試すのは上図の外部サービス、つまりコンシューマに当たる部分です。サービスプロバイダに当たるのはMySpace。ゼロから実装してもよいのですが、せっかく便利なライブラリがありますので、これのPHP版を使って試してみます。また、署名方式はHMAC-SHA1を使います。

OAuthのフローは下記の通り。この辺りを読んで仕様を理解しておく事をお勧めします。

1. リクエストトークンを取得
2. ユーザー認証
3. アクセストークンを取得
4. リソースにアクセス

リクエストトークンを取得

必要なライブラリをインクルードします。

require_once 'oauth/OAuth.php';
require_once 'oauth/OAuth_TestServer.php';

各種変数をセットしておきましょう。先程メモったconsumer_keyとconsumer_secretはここで使います。リクエストトークンを取得するためのエンドポイントはMySpaceのドキュメントに記載されています。

$consumer['key'] = 'http://devlab.agektmr.com/MyOpenSpace/DataAvailabilityExample';
$consumer['secret'] = '************';
$endpoint = 'http://api.myspace.com/request_token';

署名のロジックはめんどくさいのでライブラリにお任せ。

$server = new TestOAuthServer(new MockOAuthDataStore());
$server->add_signature_method(new OAuthSignatureMethod_HMAC_SHA1());

$sig_methods = $server->get_signature_methods();
$sig_method = $sig_methods['HMAC-SHA1'];

$consumer = new OAuthConsumer($consumer['key'], $consumer['secret'], NULL);
$request = OAuthRequest::from_consumer_and_token($consumer, NULL, "GET", $endpoint, null);
$request->sign_request($sig_method, $consumer, NULL);

$req = curl_init($request);
curl_setopt($req, CURLOPT_RETURNTRANSFER, 1);
$result = curl_exec($req);

ここまでのコードで$resultにリクエストトークンが返ってくることになります。URLのquery部と同じ形式で返ってきますので、必要に応じてパースしましょう。

parse_str($result, $tmp);

これで、oauth_tokenとoauth_token_secretが取得できたはずです。

認証

次にユーザーに認証を行ってもらいます。エンドポイントはhttp://api.myspace.com/authorizeで行います。その際、先程取得したoauth_tokenとoauth_callbackをパラメータとして付属します。oauth_callbackは認証後に呼び出されるページのURL。

$callback_url = 'http://devlab.agektmr.com/MyOpenSpace/access.php';
$auth_url = 'http://api.myspace.com/authorize?oauth_token='.urlencode($tokens['oauth_token']).
    '&oauth_callback='.urlencode($callback_url);

アクセストークンを取得

先程指定したoauth_callbackのURLにoauth_tokenをパラメータとして付属してリダイレクトされてきます。これはこのoauth_tokenが認証済みであることを示しており、アクセストークンへの交換が可能となります。

$consumer = new OAuthConsumer($consumer['key'], $consumer['secret'], NULL);
$tokener  = new OAuthConsumer($tokens['oauth_token'], $tokens['oauth_token_secret']);
$access = OAuthRequest::from_consumer_and_token($consumer, $tokener, "GET", $endpoint, null);
$access->sign_request($sig_method, $consumer, $tokener);

$req = curl_init($access);
curl_setopt($req, CURLOPT_RETURNTRANSFER, 1);
$result = curl_exec($req);

コードはリクエストトークン取得の際とあまり変わりありません。これでアクセストークンのoauth_tokenとoauth_token_secretが返っきたら準備オッケー。

RESTful APIを叩く

ここまでに取得したconsumer_key、consumer_secret、oauth_token、oauth_token_secretを使って署名したOAuthリクエストをRESTful APIに投げることにより、友達リストなどのデータ取得が可能になります。

$consumer = new OAuthConsumer($consumer['key'], $consumer['secret'], NULL);
$tokener  = new OAuthConsumer($tokens['oauth_token'], $tokens['oauth_token_secret']);
$resource = OAuthRequest::from_consumer_and_token($consumer, $tokener, "GET", $endpoint, array('format'=>'JSON'));
$resource->sign_request($sig_method, $consumer, $tokener);

$req = curl_init($resource);
curl_setopt($req, CURLOPT_RETURNTRANSFER, 1);
$result = curl_exec($req);

これでエンドポイント($endpoint)を取得したいリソースのURLにすればOK。レスポンスボディにJSON形式でデータが返ってきます。

サンプルアプリ

上記コードを使って一連の流れを見ながら動作を確認できるサンプルを用意しました。どういうリクエストを投げるのか参考になると思います。

実際に動作するサンプルはコチラ

OpenSocialでは、コンテナが外部サーバーとの通信を行う際、または外部サーバーがコンテナと通信を行う際、OAuthを使用して認可を行います。今回はOpenSocialにおけるOAuthについて、現段階でのまとめを書いてみます。 ※追記(2008/10/20)：2008/10/4に書いたコチラの記事も必読です。

OAuthって何だったっけ？

OAuthはユーザー、コンシューマ、サービスプロバイダの3者間でデータのやり取りを行うとした場合、ユーザーがコンシューマにクレデンシャル(IDやパスワード)を渡すことなく、ユーザーが所有するサービスプロバイダ上のリソースにコンシューマをアクセスさせるためのものです。 例えばユーザーがGoogle(サービスプロバイダ)のアドレス帳(リソース)をMySpace(コンシューマ)上で利用するシーンを思い浮かべてください。OAuthがなければ、MySpaceにGoogleのIDとパスワードを預けなければならなかったものが、OAuthを使うことで、ユーザーが直接Googleと認証のやりとりを行い、MySpaceにGoogleのID/パスワードを渡すことなく、アドレス帳のデータをMySpaceに渡すことができるようになります。

2種類のOAuth

さて、そんな便利なOAuthですが、OpenSocialで利用されるものには2種類あります。

OAuth Core

OAuth Coreでは、先程説明したように、ユーザー、コンシューマ、サービスプロバイダの3者間でやり取りを行います。ベーシックなものですので、詳細についてはこの辺りを参考にしてください。

OAuth Consumer Request

一方OAuth Consumer Requestは、OAuthの仕様からユーザー認証部分を除き、コンシューマとサービスプロバイダのやり取りにフォーカスした仕様で、一般に”two-legged OAuth“と呼ばれます。これはコンシューマとサービスプロバイダの信頼関係だけで、ユーザーによる認証を伴わない仕様のため、コンシューマがサービスプロバイダからパブリックな情報を取得したい場合に利用するケースが想定されます。 (かなり恥ずかしい間違いです。正確にはコンシューマが署名を付加することで、サービスプロバイダがリクエスト元とリクエスト内容に間違いがないことを確認できる仕様、です。/ 2009年10月追記)ちなみにOpenSocial v0.7ではOAuth Coreの利用は仕様に含まれておらず、このtwo-legged OAuthを利用することになっています。OAuth Coreが利用できるのはOpenSocial v0.8以降での話になります(もちろん、two-legged OAuthも利用できます)。

OpenSocialにおけるOAuth利用パターン

OpenSocialでOAuthを利用する形態として、さらに2通りが考えられます。

ガジェットが外部サーバーとやり取りを行うOutbound OAuth

ここでは仮にOutbound OAuthと呼びます。type=”html”で作られたガジェットが、SNSコンテナをプロキシとしてコンシューマの役割を果たし、サービスプロバイダとなる外部サーバーとmakeRequestで通信を行うケースです。

外部サーバーがコンテナとやり取りを行うInbound OAuth

ここでは仮にInbound OAuthと呼びます。コンシューマとなる外部サーバーがサービスプロバイダであるSNSコンテナのRESTful APIを叩くケースです。type=”url”のガジェットが外部サーバーを通してSNSコンテナのRESTful APIを叩くケースもこれに該当します。

OAuthの利用に必要なもの

OAuthの利用には前提条件がいくつか存在します。細かい仕様は別途調べていただくとして、事前に必要な条件が下記になります。

• コンシューマが、サービスプロバイダの発行する以下を事前に知っていること。
  • コンシューマキー(consumer_key)
  • コンシューマシークレット(consumer_secret)
• コンシューマが、サービスプロバイダとOAuthのやり取りを行う以下3つのURLを知っていること
  • サービスプロバイダのリクエストトークンURL
  • サービスプロバイダのアクセストークンURL
  • サービスプロバイダの認証URL

※追記(2008/10/20)：コンシューマシークレットについては、署名方式がRSA-SHA1の場合、必須ではありません。詳しくはコチラ。 OAuth利用パターンごとにどのようにしてこの条件をクリアするかを検証してみます。

Outbound OAuthのケース

ガジェットが外部サーバーとやり取りを行うケースですので、まずはガジェット開発者がSNSコンテナにコンシューマキーとコンシューマシークレットを登録します。ですが僕の知る限り、まだOutbound OAuthを実装しているSNSはありません。なので、ここでは何かしらの手段を用いて(SSLページでFormを使って投稿等)、コンシューマキーとコンシューマシークレットをコンテナに渡したものと想定してください。(今後順次、これを実現する方法は登場するものと思われます。) 次に、サービスプロバイダの各種URLを渡す必要がありますが、v0.8ではガジェットXMLで渡すよう規定されています。OAuthをModulePrefsの中に作成してください。

<oauth>
<service name="google">
<request url="https://www.google.com/accounts/OAuthGetRequestToken?scope=http://www.google.com/m8/feeds/" />
<access url="https://www.google.com/accounts/OAuthGetAccessToken" />
<authorization url="https://www.google.com/accounts/OAuthAuthorizeToken" />
</service>
</oauth>

OAuthは必ずしも1つのサーバーとやり取りするとは限りませんので、Serviceを追加することで複数をサポートすることができるようになっています。Service@nameで使い分けることが出来るようになっていますので、必要に応じてmakeRequestのopt_paramsに下記のパラメータを加え、サービスを指定してください。

gadgets.io.RequestParameters.OAUTH_SERVICE_NAME

サービスプロバイダとOAuthのやり取りを行うURLについては、XRDS-Simpleによって解決する方法もありますが、こちらについては別の機会にまとめてご紹介します。

Inbound OAuthのケース

外部アプリケーションがSNSコンテナのRESTful APIにアクセスする場合になります。これはまさに、FacebookのFacebook ConnectやMySpaceのData Availability、GoogleのFriendConnectに該当するもので、まだ実験的な段階にあると言えるものです。 コンシューマキーとコンシューマシークレットですが、SNSコンテナ上でアプリケーションを登録することで発行されます。それをディベロッパがメモ/コピペしてコンシューマとなるサーバーのコードに埋め込みましょう。URLについては、単純にヘルプページを見る方法と、XRDS-Simpleによるオートディスカバリを行う方法が考えられます。

まとめ

今回は大まかな話を書きましたが、次回は実際にMySpaceのData Availabilityを使ってOAuth認証を行い、データを取得するところまでを試してみたいと思います。

OpenSocial API仕様(v0.8)

一ヶ月くらい前から出来てたのですが、一応ブログ記事にも書いておきます。何か間違い等ありましたらお知らせください。

今更ですが、先日サンフランシスコで開かれたGoogle I/Oに参加してきました。

その中でも特に印象に残ったのが、PlaxoのJoseph Smarr氏によるOpenSocial, OpenID, and OAuth: Oh My!というセッション。僕が見たセッションの中ではダントツの人気で、部屋に用意された椅子はもちろん、立ち見で人が溢れ返るほどの盛況ぶり。

内容は、ソーシャルウェブの未来について。現在はOpenSocialというソーシャルグラフを所有するサービスに閉じた世界が中心となりつつありますが、少し未来のウェブはOpenSocial, OpenID, OAuth, PortableContacts等の技術によって、よりグローバルな意味でのソーシャル化が図れるようになる、というものです。

詳細はGoogle Codeにビデオとスライドがアップされていますので、ご覧ください。かなり早口ですが、大変面白い内容です。

OpenSocialとFriendConnectの持つ意味

OpenSocialにはv0.7まで、JavaScriptのAPIしか存在していませんでした。これはOpenSocialコンテナにとっては外部サービスからガジェットとしてアプリケーションを追加してもらい、そのOpenSocialコンテナが持つソーシャルグラフに閉じた形で利用されるものでした。アプリケーション開発者はOpenSocialのJavaScript APIを使い、ガジェットが置かれているコンテナサイトの友達リストを取得し、そこでアプリケーションを動かすことができます。もちろん、ガジェットを自分のサービスドメイン上でホスティングすることも可能ですが、ガジェットはコンテナ上でしか動作せず、友達リストを外部サービスとしてインポートしたりといったことも不可能で、実質的に囲い込みサービスしか生まれないものと言えたでしょう。

それがOpenSocial v0.8 + FriendConnectによって一気に世界を広げます。ユーザーはFriendConnect対応サイトを利用するに当たり、OAuthを使って自分が利用したいSNSサービスを選ぶ権利が与えられています。同時に、そのサイト上での活動内容は連携を選択したSNSサービスに戻されます。

ここでソーシャルサービスの要素を思い出してください。

1. アイデンティティ
2. ソーシャルグラフ(友達リスト)
3. エントリの公開範囲の制御(プライバシー)
4. フィード

FriendConnectはアイデンティティをOpenIDで、ソーシャルグラフをOpenSocial v0.8のRESTful APIで、エントリの公開範囲の制御をOAuthで、フィードをActivity Streamで解決しようとしています。

これらの意味するところを深く見つめて行くと、未来のソーシャルウェブが自ずと見えてきます。

Joseph Smarr氏(Plaxo)による未来のソーシャルウェブ論

FriendConnectのイメージをさらに深めるため、Joseph Smarr氏が、PlaxoのFriendConnect対応に際してアップしていたブログエントリをご紹介します。

Plaxo and FriendConnect are now Best Friends

Plaxoが完全にFriendConnectと連携した。FriendConnectとは、あらゆるサイトをソーシャル化する、Googleによるウィジェットベースのツールである。これにより、FriendConnectに対応していれば、どんなサイトでもPlaxoアカウントに安全に接続し、サイト上に自分の友達がいるかを確認したり、友達を招待したりといったことができるようになる。何よりも素晴らしいのは、そのサイトでの活動内容をPulseに流し込むことができるようになり、Plaxoでの友達がウェブを跨いであなたと連絡を取り合うことができ、あなたが発見した新しいサイトを知ることができる点だ。

これは本当に便利でわくわくする連携機能だ — これはユーザーが自分のアイデンティティと関係をウェブ上のどこでも利用できるようにし、新しいサイトで知人を見つけ出し、活動内容を既存の友達に共有し、よりソーシャルな発見と共有という徳の高いサイクルを生み出す、シームレスソーシャルウェブエコシステムにさらに近付いたと言える。これこそソーシャルウェブの進むべき道だ — (現在あるほとんどのサービスがそうだが)新しいソーシャルサイトを使い始める度に最初からやり直さなければならないなんてとんでもない。あなたの新しい体験全てが、他の人をも魅了すべきだ。

これはサービスがユーザーに自分の持つデータの制御を与え、オープンスタンダードを使って安全なアクセス権を提供することによってのみ成り立つ。そしてこれこそまさに、PlaxoがFriendConnectを使ってやりたかったことだ。Plaxoアカウントを接続する際、我々はOAuthを使う。そのため、Plaxoのパスワードを渡す必要もないし、後で接続を断つことも可能だ。FriendConnectを使ってあなたが活動内容をPulseに共有する際は、OpenSocial 0.8 RESTful Activities APIを利用する。オープンスタンダードではない連携はアドレス帳APIのみであり、我々はこのスタンダードについても取り組みを開始している。我々はアイデンティティプロバイダとして、ソーシャルグラフプロバイダとして、そしてコンテンツアグリゲータとしての役割を果たしていると強く信じている — つまり、我々はユーザーが自身のデータと関係性をウェブ上のどこにでも持ち回り、どこからでも共有できるようにしている — これはユーザーにとっても、Plaxoにとっても、ウェブ全体にとっても有益なことだ。だが、まだこの取り組みは始まったばかり — FriendConnect対応サイトから活動内容を共有する際、家族や友達、仕事関係など、共有相手をより細かい粒度で制御するなどの、更なる拡張を楽しみにしていて欲しい。

下のスクリーンショットはPlaxoとGoogle FriendConnectの連携したものだ — FriendConnectを利用しているサイトでも体験してもらうことができる。

画像は実際のページをご覧下さい。

まとめ

ガジェットコンテナとしてのOpenSocialには正直、懐疑的な部分があったのですが、FriendConnectの描く未来を想像し、またわくわくしています。今後もこの辺りの動向を追って行きます。

追記

似たような話題に触れた記事を見つけたので追記し、トラバっておく。(失敗したので断念○|￣|＿)

グーグルが見たソーシャルネットワーキング–その3つの傾向:スペシャルレポート – CNET Japan

これまで公開していたOpenSocial RESTful API Proposalの翻訳を、OpenSocial v0.8仕様のリリースで公開されたOpenSocial RESTful API Specificationに置き換えました。

ただし部分更新処理の項目についてはTBD(To Be Determined)のままになっています。問い合わせしているので、最新版に更新され次第アップします。

OpenSocial v0.8のRESTful API仕様では、オートディスカバリにXRDS-Simpleを利用するよう規定されています。

他方、OpenSocial v0.8で利用されるRESTful APIはAtomPub形式となっており、AtomPubではService Documentを利用するよう規定されています。

これではコンテナサイトがどちらを使うのか、両方使うべきなのか疑問が残ってしまいます。この件について、Google GroupsのOpenSocialの仕様を検討するグループに質問を投げてみました。

質問

コンテナサイトはAtomPubのService DocumentとXRDS-Simple、どちらを採用すべきなのでしょうか？両方サポートすべきでしょうか？

David Primmer氏の回答

AtomPubのService DocumentはURLの一部をテンプレート的に定義して変数を当てはめる用途には向いていない。ある程度固定されたURL上で指定することを想定されているようだ。
その点、XRDS-Simpleは空白に値を埋める形でURLをディスカバリできる点で優れている。

この点に関しては、AtomPubのPerlライブラリを実装されたたけまるさんも指摘されていて、XRDS-Simpleを利用する方が合理的であるという点では一致しています。

ただ、仕様に適合しないという意味では気持ちの悪いものであることは間違いなく、この点をどこかで解決できないかと考えています。先ほど紹介したGoogle Groupsで「AtomPubの仕様作成者に仕様変更の提案を行う予定はあるか」との質問を投げたのですが、その後応答はありません。

現時点でRod Yatesという方からこちらの仕様書から適用できるのではないかとの提案を頂いているので、AtomPub識者の方と相談して何かしらの働きかけを行っていこうと思います。

OpenSocialコンテナにもOrkut, hi5, MySpaceだけでなく、iGoogle, hyves, Netlogなどが登場してきました。

それぞれのSNSには特徴がありますが、仕様をいちいち調べたり、開発に当たって動作確認を行うのは面倒です。現在OpenSocial v0.8は登場したばかりということもあり、ほとんどがv0.7対応のものですが、v0.7への対応状況を確認できるガジェットというのがあります。

これで開発も少しは楽になるのではないでしょうか。

OpenSocialのコンテナと言えばShindigですが、PHP版は既にOpenSocial v0.7への対応を完了しています。Partuza!はPHP版Shindigの開発者であるChris Chabot氏がオープンソースで開発したShindig対応SNSです。

Shindigがコンテナなのに、じゃあPartuza!は何をするの？と思われるかもしれません。今回はインストール方法と、Shindigとの関係について解説します。

Partuza!をインストールする

Shindigのインストール方法は以前解説しましたので、ここでは割愛します。仮に、Shindigが~/shindig配下にインストールされ、http://localhost:8080/gadgets/…でアクセスできるものとします。

まず、環境としてApache、PHP5(要mcrypt)、MySQL5が必須となります。

レポジトリからチェックアウト

Google CodeのレポジトリからSVNでチェックアウトします。

> svn checkout http://partuza.googlecode.com/svn/trunk/ ~/partuza

データベースを用意

適当なデータベース名、ユーザー名、パスワードで空のDBを作ってください。ひとまずここではそれぞれ、partuza、root、パスワードなしとします。この状態で、~/partuza/partuza.sqlをダンプします。

> mysql -u root partuza < partuza.sql

DocumentRootを設定

Apacheの設定(httpd.conf)でDocumentRootを~/partuza/htmlに設定し、http://localhost/でアクセスできるようにします。もちろん、Shindigとは別ドメインを用意する必要がありますので、バーチャルホストを使う等してください。

設定ファイルを修正

~/partuza/html/config.phpを編集します。ここでは先程作成したデータベース関連の情報とガジェットサーバーのルートURL(gadget_server)を設定します。ガジェットサーバーのURLが、ここではShindigのURLとなりますので、http://localhost:8080/になります。

データベースハンドラをコピー

~/partuza/Shindig/PartuzaDbFetcher.phpと~/partuza/Shindig/PartuzaHandler.phpを~/shindig/php/src/socialにコピーします。

> cp ~/partuza/Shindig/Partuza* ~/shindig/php/src/social

Shindigのデータベース設定を修正

~/shindig/php/src/social/PartuzaDbFetcher.phpにもデータベース関連の情報があるので修正します。加えてShindigがデータベースハンドラを利用するよう、~/shindig/php/config.phpも修正します。ここでは、”handlers => PartuzaHandler”としてください。

これで一通りの準備は完了。http://localhost/にアクセスしてウェルカム画面が出れば成功です。このまま登録し、Orkutライクな一般的なSNSとして利用することができます。

Partuza!とShindigの関係

OpenSocialのガジェットがiframeを介して表示されていることは以前も解説しましたが、簡単に言ってしまえば、iframeの手前がPartuza、後ろがShindigになります。Shindigでは以前から下記のURLにアクセスすることで簡易的なHTMLからOpenSocialぽい表示を行うことはできていましたが、Partuzaを使うことで完全なSNSとなります。

とはいえ、PartuzaHandlerを指定したところからも想像できるように、データベースは共有されます。なお、Chris Chabot氏のサイトで実際に動いているものを確認することができます。

Partuza!を使うことで、どうすればShindigをSNSに組み込むことができるかの解析をすることができるだけでなく、そのままちょっとしたSNSを開発することもできてしまいます。ぜひお試しください。