1
jeeson 2013-03-16 17:58:17 +08:00
Reeder 在 Twitter 上说不会和 Google Reader 一起 Over。许多 客户端应该都还在犹豫中。
最差情况下就是从客户端抓阅读源,退回到八年前的技术。 |
2
kunimi 2013-03-16 17:59:23 +08:00 via iPad
|
3
K2 2013-03-16 21:53:01 +08:00
feedly 能做的 reeder 也能
|
4
ccming 2013-03-16 22:26:09 +08:00 via Android
正是reeder的机会,现在digg也要插一脚呢
|
5
chrisyipw 2013-03-16 22:35:19 +08:00
Reeder 至少可以做两件事:1. RSS 源从 Google Reader API 转到本地实现;2. iCloud 同步 RSS 源。
第一点有很多成熟的东西可参考、可借用,根本不成问题。 第二点因为是用 Apple 的东西,Reeder 不需要支付硬件成本。 到 Google Reader 关闭之前,Reeder 有足够的时间完成上面两点。RSS 阅读器其实属于泛滥的程度,2000 前后就有很多优秀的离线阅读器,所以根本不担心「Google Reader 死了,Reeder 也会死」之类的事情——只要开发者不放弃。 |
6
yyfearth 2013-03-16 23:19:07 +08:00
同意楼上各位的
到时候各种云阅读服务会起来,reeder只要多支持一些API就好了 同时可以提供本地抓取的功能,然后icloud同步订阅保险。 抓取的内容也可以云同步作为备份。 |
7
jeeson 2013-03-16 23:51:49 +08:00
@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 |
8
yyfearth 2013-03-17 08:17:05 +08:00
@jeeson 当然这些事情给云服务来做了更好了,所以当然是有API就用别人的API,没有再来本地。
用iCloud,至少相同Apple ID的所有设备同步是没问题的了,要支持的更广可以用Dropbox啊。 还可以把抓下来的文章存档成HTML备份不就不怕丢了么。 |
10
mufeng 2013-03-17 15:38:03 +08:00
现在蛮希望有个网页版的
|