我需要从 rss 提要创建一个项目数据库，并且我希望它能够异步更新（通过推 ala AJAX）而不是拉（通过 php 中的 python/magpie 抓取 RSS）。该数据库将用于分析而不是应用程序，因此它需要扩展。如果有人知道一个 rss 提要阅读器应用程序，您可以通过 xml 从提要中简单地导出项目，那就太好了。
我不希望创建一堆服务器基础设施来让 php rss 解析器在 chron 作业上与 mysql 一起玩，但如果有必要我会这样做。也对潜在的 python 解决方案感兴趣。
我查看了 Superfeedr/PubSubHubbub，但不确定这是否适合我。
请在我的评论中加盐，因为我创建了Superfeedr。无论如何，我会尽量保持客观。
如果您想扩大规模，并希望您的数据集持续增长，那么（正如您所猜测的）轮询可能会非常困难。您可能会花费大量时间处理 HTTP 问题和 XML 解析问题。在 Superfeedr，我们已经在获取和解析数以百万计的提要，而且没有一周我们不会遇到新的“种类”错误。我有时觉得自己是亚马逊雨林的第一个定居者。
在 HTTP 问题中，您显然会看到一些服务阻止了您，因为它们发现您的请求过于激进，而且您还必须处理其中一些服务的停机时间，这可能会减慢整个系统的速度。当然，我不是在谈论处理 HTTP 标头时的模棱两可（我们知道一些服务器在Etagand之间有所不同etag，而有些服务器只接受带引号的 etag ......而其他人会拒绝它们......）
在 XML 方面，情况更糟。首先，您必须能够解析如此多的汤，以至于您可能可以养活世界（双关语！）。对于许多忘记转义是必要的、名称空间有前缀的 Web 开发人员来说，XML 似乎是一门非常复杂的科学，但也忘记了most <open> tag must eventually be </closed>. 现在，您还必须处理 RSS、ATOM 或 RDF 的风格，并处理所有这些。
一旦确定了正确的格式，您还必须理解数据。我总是在提要中引用时间戳，因为人们往往会把它们弄得一团糟。我们发现的一些提要甚至将“昨天”显示为<published>日期。那有多可爱？现在，对于那些使用机器可读时间戳的人，您会看到一些只有数字值，而另一些则是 06/03/2012。即使他们使用正确的格式（未在 RSS 规范中指定！），人们不了解时区的工作方式（对于未来发布的内容！）甚至夏令时也并不罕见。最后，这实际上是一个合理的观点：某些提要不使用我们的公历，而是使用阿拉伯日历。
区分（识别新旧东西）也非常困难，因为时间戳是错误的，而且还因为例如 RSS 1.0 没有<id>. 构建一个很难，因为很多人会将跟踪代码（更改！）放在链接中，甚至放在他们的条目正文中:(
简而言之，轮询是一团糟，而且很难大规模处理。现在，如果您走这条路，请务必使用PubSubHubbub开放协议。这对你来说是一小步，但对 webmanity 来说却是一大步，因为它将增加采用率，如果一切顺利，我们最终可能会完成投票。好消息是很多平台都采用了它，这应该会大大减少您的投票需求。
你想要构建的东西对我来说并不明显，但我相信使用像Superfeedr这样的解决方案是一个好方法。我们将处理所有 HTTP 问题，并尽可能规范化 XML，以便您更容易使用（我们甚至可以将其转换为 JSON）。是的，我们对我们的服务收费，但它也为您节省了很多时间，这样您就可以专注于使您的服务/数据存储与其他人真正不同的地方。
提要通常通过 HTTP GET 访问，因此除非您愿意使用第 3 方应用程序（例如 Superfeedr），否则没有真正的推送选项。
话虽如此，pull 选项还不错。这取决于您要聚合多少数据。对于“读取和导出”，大多数桌面提要阅读器可能在数量上存在问题，但是没有像Venus这样的所有 GUI 开销的东西可能会让你走得很远。
提要格式和质量的变化是一个大问题，但是有一些库可以解决这个问题——Python feedparser特别好。
设置提要轮询并将结果通过解析器推送到数据库中不需要太多代码。（如果您自己设置了轮询，请务必检查 ETags 和 Last Modified 标头 - 或让 feedparser为您完成）。