- フィードを更新するためのAPIがあると便利です
- クローラを別ホストで動かしたり、別言語で書いたり、特殊用途向けのクローラが書きやすくなります。
- 管理者向けメリット: クロールを外部サービスに分離できる
- ユーザー向けメリット: APIに直接POSTしてフィードじゃないものを読めるようになる
- サイト運営者向け: 将来的なこと考えるとフィードを各々好き勝手クロールする状況は効率が悪い → 更新のタイミングでPush
- Bloglinesには専用のメールアドレスを発行してそこにメール送るとフィードとして読めるみたいな機能があった。
- メール送る → 読める シンプルで万国共通、でもSMTPは面倒くさい
- フィードが無いものを読めないというのは困るんだけど、フィード作ってクロールさせるというのは無駄が多い
- クローラからアクセスできる箇所に生成したフィードを置いておく必要がある → プライベートなデータを置けない
- WebHookでの更新
- PubSubHubbub
- superfeedr
- http://blog.superfeedr.com/json-pubsubhubbub-notification/
- https://code.google.com/p/pubsubhubbub/
現状はこんな具合
- SNSサービスの更新 → スマホアプリ → GoogleやAppleの通知サーバー経由で
- お知らせメール配信 → ユーザー側の設定で転送等 → 各々のメールクライアントによる通知
通知サービスは時代遅れのメールか、モバイルOSの提供ベンダーによる寡占状態にある
- プッシュ通知が出来るようにするにはどうすればいいか
- https://wiki.mozilla.org/Services/Notifications
- API経由でのPOSTを受けたらフィードの購読設定に応じて何らかのアクションが起こせると良い
- 皆各々好き勝手フィード取ってくると更新のタイミングでの付加がハンパない → PubSubHubbubできた経緯
- これはフィード内に指定があるHubに対して購読要求を送ると、更新があった際に通知を送ってくれるものです。
- tumblrやbloggerなどが対応しています。
- ただ、subscriber側が外部からアクセスできる必要があります。ローカルやイントラ向けには使いにくいです。
- weblog update pingは無駄が多すぎました。何をどう間違えたのかspammerしか使ってません。
- すごく更新頻度が高いなら接続しっぱなしが良いということになります。(Twitter)
- そうでないならつなぎっぱなしにするのは非効率なので pubsubhubbubのようなアプローチが正しいです。
- あんまり負荷が高いとフィード公開するデメリットのほうが大きくなってしまう
- Twitterのようなサービスにとっては実際に割にあわない。
livedoor Readerではどうしているかというと broker, fetcher, parser, updater という具合に独立したworkerプロセスが動いています。 どこまで分離が可能か → feed discoveryで実際にパースするのか見るので、Web側にもどっちにしろパーサー用モジュールは必要
- どのフィードをクロールすべきか / データベースへの書き込み を Webサーバー側に持たせてAPI化する
- クローラ側がDBスキーマ知る必要が無い状態にする
- 最低限実装のクローラの場合は、データベースを持たないで済む(cronでリスト取ってきてクロールしてWebにPOSTするだけ)
- ただしクローラ側が独立してキャッシュしたり、更新検知、差分検知するのはありだろう
- フィード全体: if-modified-since を使う
- フィード全体: 改行、スペースやタブや内容に影響ない要素を除去した上でハッシュ値とって保存しておいて前回と比較
- 記事毎: 記事ごとにハッシュ値作って使う → 1記事ごとに比較すると結構なコストがかかる
- フィード毎に既出の記事かどうか判定するためのデータを作ってキャッシュしておくと高速化出来る
- [feed_id,link,digest] でユニーク判定する
- クローラ側で独立して「どの記事が新着か」判断するためにはDBアクセスが必要になってしまう