Buzzttraをいじってみてのとりあえずのメモ
kgbu/buzzttra · GitHubとりあえず、ガラケーに認証情報を転送して、Buzzを表示したり、投稿することができるのは確認できた。
これから先に進むかどうかを考えるためにまとめ中。随時追記の予定。github上のissuesにもいくつかネタが置いてある。
SinatraはThinと組み合わせるものだったのか
Sinatraだけをgem installした段階ではwebrickが立ち上がるが、
require 'thin'
とすれば、Thinで立ち上がる。並列処理の性能というかスレッドセーフ性のテストはまだしていない。
携帯のような比較的低速の通信相手の場合、サーバや回線への負荷が限界より低くても、かなりの並列度（数百以上）で処理できないとアクセス数が稼げないので、並列度は重要。webrickが起動した状態ではab(Apache Bench)の結果を見る限り、並列実行を実感できなかった。これは個別の処理の負荷が軽すぎたせいかも。コードを見る限り、リクエストごとにスレッドが起動されている。
SinatraとThinという組み合わせに意義を感じるのは、サイトのコンテンツのパーツとして高頻度で使われるパーツの実装にはちょうどいい落とし所のように思えるから。
本体をRailsとするならば、Rack::Sessionが共通にできそうだという目論見もある（それがsecureにできるかどうか、サーベイしてからの判断になるだろうけど）
サービスのパフォーマンスの面では、大量かつ高頻度のデータ更新を行うつもりなら、event machineのライブラリも一度テストしてみたいと思った。
そもそも、Buzzのconsumptionのデータを毎回取得するなんて、Buzz側からすれば迷惑かもしれないし、レスポンスも低下するので、データのキャッシュと更新の部分をバックエンドに組みこみたくなる。
更新検知に関しては、PuSHがそれなりに動いてはいるので、それを使うこともアリだとは思うのだが、consumptionのデータに関しては、サービス利用の認可を取っていない他のユーザのデータの更新検知もできなくてはいけないので、consumptionのデータ取得はそれなりにやっとかないといけないような気もする。その場合、max-results = 10くらいにしておいて、数分に1回アクセスするとか、更新頻度によっては間引くとかの工夫も必要になるだろう*1
主要サービスのOAuthはガラケーを相手にしていない
nahiさんのまとめを見て涙してしまった。
えーかげん見限ってAndroiodを相手にするタイミングなんだろう。
ver. 2.2ネイティブの機種を待たなくてもよかろう。iPhoneはもう参入するには遅いし、AppleのUIは、見せてもらった限りでは自分の趣味ではなかった。「酸っぱい葡萄」なんだろうけど、無理してもダメだろう。
携帯に転送した認証のrevokeってどうなるだろう
ガラケーに認証情報(tokenとsecret)を転送するのは、一時的に有効なURLをメールで送って、そこにアクセスさせてcookieを付与する方法を取っている。
その情報をrevokeするには、今はサーバを再起動すれば、認証のやり直しになるので、個人で使う分にはそれで問題ないけれど、他のユーザの認証の状態（現在はcookieにセッション情報を保存している）を保持したまま、自分のPCのアカウントも再認証せずに、携帯に払い出した認証のtokenを無効にする手段が欲しいと思っている。
そもそも、メールを使って認証情報を携帯に送ってたりするところで、それが他人に漏れたらダメではあるのだが、有効期限を5分に限ってあることと、他人がその認証情報を使ったら、今度は自分がその認証情報でログインできない時点で、盗用の可能性に気付くところまでは作ってみた。後は盗用されているtokenをrevokeできればいい。
うーん、再認証しちゃうかー。それが簡単でいいな。
(追記)URIの設計、RESTの適用範囲
正直、RESTって何なのか、というか何のためなのかピンときてません。
もともとのHTTPがGET, POSTの他にPUT, DELETEなどのverbをもっていたのは、HTML「文書」をオブジェクト（文法的にはsubject:主語足りうるもの）ととらえた場合にはごくごく自然な発想だったと思う。
URIで指定されるものが文書オブジェクト*2だけであるならば、Webサービス全体がRESTfulってのはアリかもしれないが、現実にはWebサービスの本体はuser experienceの場なわけで、それはresourceとは限らない。
現実には、RESTfulになっているのはresourceアクセスのAPIと呼んだほうが混乱が少ないのではないかと思う。
というわけで、自分がSinatraで最初に作ったのは、RESTfulなBuzzのAPIのproxyのようなものだった。
これを、Javascriptで作ったUX(user experience)から随時参照して、mash-upしようと考えた。
そうすれば、通常のブラウザがPUTやDELETEなどのverbをサポートしない問題に直面せずにすむ。
ただし、現在のURIの構成は、APIとUXがごちゃまぜになっているので、改善の必要がある。PC版と、Javascript-freeなガラパゴス携帯版の切り分けも結構難しい。（この辺はRailsだったらなー、とか思うことがしばしばあった）
(さらに追記)SOPの制約とか
JavascriptのSame Origin Policyの制約のため、resourceアクセスのAPIとUXのURIがどうしてもかぶっちゃうのが気持ち悪い。とか思っていたな、とりあえずメモ。
携帯でアクセスする場合には、cookieがホスト名単位でマッチしてないと使えないっていう問題もあったな。cookieの話は、PCのブラウザは結構融通が効く（逆に言えば互換性の問題になってしまうという話もあるんだろう）。
そもそも、携帯からSSLアクセスしてもらうには、ちゃんとしたところの証明書が必要で、金がかかる。一方、携帯のブラウザにはアドレスバーが表示されないことが多い（と思う）ので、SSLの暗号化による盗聴防止しか機能していないのは皮肉だ。金のかかった証明書を使っていることはわかるが、自分が接続するつもりだったサイトなのか、アドレスバーで知ることができない。（メニューで詳細表示とかする必要があると思う）
