在上一篇文章中，我描述了自己如何重制了一个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那样面向过程开发的方法…

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