与 Google Reader 同步时如何跳过已知条目？

Question

为了将离线客户端写入 Google Reader 服务，我想知道如何最好地与该服务同步。

似乎还没有官方文档，到目前为止我发现的最好的来源是：http://code.google.com/p/pyrfeed/wiki/GoogleReaderAPI

现在考虑一下：使​​用上面的信息，我可以下载所有未读项目，我可以指定要下载的项目数量，并使用 atom-id 可以检测到我已经下载的重复条目。

我缺少的是一种指定我只想要自上次同步以来的更新的方法。 我可以说给我 10 个（参数 n=10）最新（参数 r=d）条目。如果我指定参数r=o（日期升序），那么我也可以指定参数ot=[last time of sync]，但只有这样并且升序不会'当我只想阅读一些项目而不是所有项目时，这没有任何意义。

知道如何在不重新下载所有项目并拒绝重复项的情况下解决这个问题吗？不是一种非常经济的投票方式。

有人提议我可以指定我只想要未读条目。但要使该解决方案以 Google Reader 不再提供此条目的方式工作，我需要将它们标记为已读。反过来，这意味着我需要在客户端上保持我自己的已读/未读状态和，当用户登录到 Google 阅读器的在线版本时，这些条目已经被标记为已读。这对我不起作用。

干杯， 马里亚诺

Answer 1

Google API 尚未发布，届时此答案可能会发生变化。

目前，您必须调用 API 并忽略已下载的项目，正如您所说，这并不是非常有效，因为您每次都将重新下载项目，即使您已经拥有它们。

Answer 2

要获取最新条目，请使用标准的 from-newest-date-descending 下载，该下载将从最新条目开始。您将在 XML 结果中收到一个“继续”标记，如下所示：

<gr:continuation>CArhxxjRmNsC</gr:continuation>`

浏览结果，找出任何新的东西。您应该会发现要么所有结果都是新的，要么在某一点之前的所有内容都是新的，并且之后的所有结果都是您已知的。

在后一种情况下，你已经完成了，但在前一种情况下，你需要找到比你已经检索到的旧的新东西。通过使用 continuation 从您刚刚检索到的集合中的最后一个结果之后开始获取结果，方法是在 GET 请求中将其作为 c 参数传递，例如：

http://www.google.com/reader/atom/user/-/state/com.google/reading-list?c=CArhxxjRmNsC

继续这样，直到你拥有一切。

n 参数，它是要检索的项目数的计数，与此配合得很好，您可以随时更改它。如果检查频率是用户设置的，因此可能非常频繁或非常罕见，您可以使用自适应算法来减少网络流量和处理负载。最初请求少量最新条目，比如五个（将 n=5 添加到 GET 请求的 URL 中）。如果都是新的，在下一个请求中， 在你使用延续的地方，要求更大的数字，比如 20。如果这些仍然是新的，那么提要有很多更新或者已经有一段时间了，所以以 100 人为一组继续。

---

但是，如果我在这里错了，请纠正我，您还想知道，在您下载一个项目后，它的状态是否会由于使用 Google 阅读它的人而从“未读”变为“已读”阅读器界面。

一种方法是：

1. 在 google 上更新已在本地读取的任何项目的状态。
2. 检查并保存提要的未读计数。 （您希望在下一步之前执行此操作，以确保在下载最新项目和检查阅读计数之间没有新项目到达。）
3. 下载最新项目。
4. 计算您的阅读次数，并将其与谷歌的比较。如果 Feed 的阅读次数比您计算的要高，您就知道有人在 google 上阅读过。
5. 如果已在 google 上阅读过某些内容，请开始下载已阅读项目并将其与您的未读项目数据库进行比较。您会发现一些 google 说已读取的项目，而您的数据库声明未读；更新这些。继续这样做，直到您找到的这些项目的数量等于您的阅读计数与 google 的差值，或者直到下载变得不合理为止。
6. 如果您没有找到所有已读项目，c'est la vie;将剩余的数字记录为“未找到的未读”总数，您还需要在下次计算您认为未读的本地数字时将其包括在内。

如果用户订阅了很多不同的博客，他也很可能对它们进行了广泛的标记，因此您可以基于每个标签而不是整个提要来完成这一切，这应该有助于保持数据量下来，因为您不需要为用户没有在谷歌阅读器上阅读任何新内容的标签进行任何转移。

整个方案也可以应用于其他状态，例如已加星标或未加星标。

现在，正如你所说，这个

...这意味着我需要在客户端上保持自己的已读/未读状态，并且当用户登录在线版 Google 阅读器时，这些条目已被标记为已读。这对我不起作用。

确实如此。保持本地已读/未读状态（因为无论如何您都保留了所有项目的数据库）或在谷歌中标记已读项目（API 支持）似乎都非常困难，那么为什么这对您不起作用？

---

不过，还有一个问题：用户可能会在 google 上将已读内容标记为未读。这给系统带来了一些麻烦。我的建议是，如果你真的想解决这个问题，假设用户一般只会接触最近的东西，每次下载最新的几百个左右的项目，检查所有的状态他们。 （这并不是所有那么糟糕；下载 100 个项目让我从 300KB 的 0.3 秒到 2.5MB 的 2.5 秒，尽管在非常快的宽带连接上。）

同样，如果用户有大量订阅，他也可能拥有相当多的标签，因此按标签执行此操作会加快速度。实际上，我建议您不仅要按标签检查，还要分散检查，每分钟检查一个标签，而不是每 20 分钟检查一次。您还可以对旧项目的状态更改进行这种“大检查”，而不是进行“新内容”检查，如果您想降低带宽，可能每隔几个小时检查一次。

这有点占用带宽，主要是因为您需要从 Google 下载完整文章来查看状态。不幸的是，在我们可用的 API 文档中，我看不到任何解决方法。我唯一真正的建议是尽量减少对非新项目的状态检查。