关于pubsubhubbub和Google Reader

上一篇文章中,我描述了自己如何重制了一个Danbooru的feed。然而,经过一夜的睡眠,我「惊喜」地发现Google Reader在睡前到醒后的7个多小时里面都没有抓取过我订阅了的这个feed——也就是说,就算重制的feed包含10000条最近更新,只要GR不主动抓取,那这些更新也还是没有意义。

绝望之下,觉得归根到底还是弄清楚pubsubhubbub(以下简称PuSH)协议的原理。试着搜索有关GR和PuSH的文章,发现@keakon曾经发表过『PubSubHubbub不通知Google Reader的原因』『实现PubSubHubbub订阅』和『使用PubSubHubbub』三篇文章。拜读之后,明白了什么叫publisher和subscriber,也得知GR可能会自动忽略订阅数少的feed的PuSH,于是先写了一个sub,然后拿菜包工作室来当小白鼠(不好意思啦@tc201158),由于这个博客刚开张,只有我一个人在GR订阅了(订阅数为1),在装了PuSH插件并在hub上进行subscribe之后果然还是无法实现PuSH,可是我用另外一个GR帐号订阅其feed(订阅数为2)之后,PuSH就能正常工作了。

大喜,以为终于找到了原因,于是对重制的feed也如此这般地弄,结果却失败了…无奈之下,我又试着对danbooru的原feed重新在hub上subscribe,发现原feed实现了PuSH的同时,重制的feed也实现了PuSH!难道因为重制的feed中提供的id、url等信息仍然是原feed的信息,所以只有在收到原feed更新的ping请求后,hub才会通知GR抓取重制的feed?

不过既然原feed能够实现PuSH,那重制的feed就没什么意义了;只需要实现在GAE上利用cron定期检查原feed是否有更新,有的话就ping一下hub就可以了。于是又浪费了一整天的人参来实现了这个功能…

至此,对Danbooru feed的PuSH改造完满完成。经验教训:

  1. 尽管有约定,但在feed中添加hub link并不是必须的,至少对于Google的hub(http://pubsubhubbub.appspot.com)是如此;
  2. 利用第一点,可以对任何一个feed实现PuSH改造。先写一个sub以便在Google的hub上对feed进行订阅(必须有订阅才能实现PuSH),然后写一个cron定期检查feed的更新并且ping hub即可;
  3. 开发GAE应用时,利用handlers和wsgi来架构整个应用,无论是应用结构还是debug都方便太多了,决定从此放弃像twitter2weiboviagtalk那样面向过程开发的方法…

题外话。今天是⑨月⑨日的⑨节,可是⑨的同人图一点都不给力啊…

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.