Google Apps x SAML
http://code.google.com/apis/apps/sso/saml_reference_implementation.html
よかったねえ。これでSAML陣営も弾みがつくといいですね。５年間ではなかったレベルのいい事例でしょう。ちょっと見切り早かったかな？でも仕方ないね。Salesforceも見習うべきだと思います。
まあ問題は、きっとOutlookなどのデスクトップクライアントとの連携が求められるだろうのに、当面はせっかくのSSOは利用できず結局パスワード同期を必要としてしまう点。あと、コンシューマ向けはそのままGoogle Account APIで行くのだろうな。
Comet接続のJSONP
Cometで複数同時コネクション数制限を回避するための、JSONP以外の回避方法(IFRAME+XHR)について書いてあったのだけど、
http://labs.cybozu.co.jp/blog/kazuho/archives/2007/02/keeping_comet_alive.php
この中のスライドの１０枚目に、JSONPがつらい理由？として「セキュリティリスク or パフォーマンス劣化」というのがあって、セキュリティリスクはわかるけど、パフォーマンス劣化は何を指してるのだろう？？純粋にちょっと分からなかった。
まあそれはいいとして、自分の知る限り、複数のCometセッションが必要な場合にJSONPが適切でない最大の理由は、動的JavaScriptロードの評価順序がブラウザによって違うというところなんじゃないかなと思う。例えばFirefoxではscript要素を追加実行した順番にスクリプトが評価されちゃう。ロードされた順じゃない。つまり、同一ページ内にチャットルームが２つ以上あるなら、１つのルームの発言タイミングまでその他のルームの発言の更新が引きづられる可能性があるということで、これじゃあCometの意味があまりない。
以下にその辺の経緯が。
http://d.hatena.ne.jp/ladybug/20060926#p2
http://d.hatena.ne.jp/shinichitomita/20061013/1160707042
http://la.ma.la/blog/diary_200610131704.htm
PipesのJSONP
http://www.popxpop.com/archives/2007/02/yahoo_pipesbadger.html
http://kentbrewster.com/badger/
なんだ、JSONだけじゃなくってJSONPもいけるんじゃん。いいぞいいぞ。
Yahoo Pipes
http://pipes.yahoo.com/pipes/zIQi0Iy72xGJ3NMhJhOy0Q/run?_render=json&s=http://d.hatena.ne.jp/shinichitomita/rss&_callback=handleFeeds
つまり、RSS2JSONPサービスとしても使えるってことだ。いままでにもそういうサービスはあったけど、ほとんど個人が好意でやってるものだった。非個人がサービスしているということ、しかもYahooという企業の信用レベルを考えればこれはすばらしい。単にScalabilityやAvailabilityという尺度だけではなく、JSONPではJavaScriptとして配信されるがためにプロバイダへの信頼が必要になってくるからだ。
ありがとう、Yahoo！ (U.S.)
