Google Reader撤了，Reeder还会有用么？

[zhangxiao]

[jeeson]

Reeder 在 Twitter 上说不会和 Google Reader 一起 Over。许多 客户端应该都还在犹豫中。

最差情况下就是从客户端抓阅读源，退回到八年前的技术。

[kunimi]

https://twitter.com/reederapp/status/311995748482945025

[K2]

feedly 能做的 reeder 也能

[ccming]

正是reeder的机会，现在digg也要插一脚呢

[chrisyipw]

Reeder 至少可以做两件事：1. RSS 源从 Google Reader API 转到本地实现；2. iCloud 同步 RSS 源。

第一点有很多成熟的东西可参考、可借用，根本不成问题。

第二点因为是用 Apple 的东西，Reeder 不需要支付硬件成本。

到 Google Reader 关闭之前，Reeder 有足够的时间完成上面两点。RSS 阅读器其实属于泛滥的程度，2000 前后就有很多优秀的离线阅读器，所以根本不担心「Google Reader 死了，Reeder 也会死」之类的事情——只要开发者不放弃。

[yyfearth]

同意楼上各位的
到时候各种云阅读服务会起来，reeder只要多支持一些API就好了
同时可以提供本地抓取的功能，然后icloud同步订阅保险。
抓取的内容也可以云同步作为备份。

[jeeson]

@chrisyipw
@yyfearth

如果没有 Google Reader 这种提供 API 服务的中心：
1, 标星，已读 等状态在不同应用，甚至相同应用相同帐号在不同设备之间同步都会成为问题。用户的迁移成本也提高

2, 有较多订阅源的用户来说本地直接抓取效率很低
如果订阅源不支持根据上次抓取时间来返回结果的话（比如通过 header 中的 ETag），对订阅源和客户端都是负担，尤其全文 feed

3, 客户端要处理 rss 和 atom 两种格式，许多 feed 的输出并不规范，需要不少错误处理


比如，获得最新更新，从 Google 服务器只要一个请求，GET 0/stream/contents/?n=请求数量&ot=上次更新时间&xt=user/-/state/com.google/read，通常可以在几秒内完成更新

而如果在客户端，需要逐一向各个订阅源请求，并且每个订阅源可能都会返回最新的 n 篇文章


不知道 Digg 最后能否以应用开发商能负担的起的成本提供得起这种 API

[yyfearth]

@jeeson 当然这些事情给云服务来做了更好了，所以当然是有API就用别人的API，没有再来本地。
用iCloud，至少相同Apple ID的所有设备同步是没问题的了，要支持的更广可以用Dropbox啊。
还可以把抓下来的文章存档成HTML备份不就不怕丢了么。

[jeeson]

@yyfearth @yyfearth iCloud 或许可以同步一本书之类的，但不能处理数据的记录级比较更新

[mufeng]

现在蛮希望有个网页版的