是否有一个ATOM客户端或框架可以完全捕获一次Feed条目？
如果没有，最好的架构是什么？
我们想要解析ATOM提要，将所有联合供稿条目本地保存为单个记录（在数据库或文件系统中）。为了提高效率，可能必须定期删除这些记录。因此，客户必须独立地跟踪已经查看过的条目 - 持久性。
答案 0 :(得分：0)
你看过Superfeedr了吗？它是一个软件即服务平台，可以实现这一目的：获取源，解析它们并在新端点可用时将新条目发送到端点。
答案 1 :(得分：0)
回答我自己的每个工作解决方案。总之，从联合供稿中仅捕获新的和唯一条目的架构解决方案是 - CACHING。
具体而言，客户必须存储条目以支持逻辑“Feed对我来说有什么新东西吗？”。我相信这种“客户端”解决方案没有捷径可走。
Conditional-GET不是一个完整的解决方案，即使由联合供稿支持服务器端也是如此。例如，如果客户端客户端未发送准确的 If-Modified-Since 时间戳，则服务器可以忽略标头并再次生成所有条目。每Chris Berry, Bryon Jacob. Updated 10/27/08，
...更好的方法是使用start-index参数，客户端将此值设置为上一页返回的end-index。使用start-index确保客户端永远不会看到相同的响应两次，或者错过条目，因为几个条目可能具有相同的“更新日期”，但永远不会具有相同的“更新索引”。
简而言之，没有标准的服务器端解决方案保证“新/唯一”。 “唯一性”的概念无论如何都是客户端问题，服务器可能无法共享相同的意见。从这个角度来看，服务器不可能满足所有客户。而且，无论如何，这个问题与开发更好的联合服务器无关，而是一个更聪明的客户端，因此，缓存是可行的方法。
缓存实现必须在feed轮询之间保持，并且存储在缓存中的条目的生存时间（ttl），空闲时间（tti）属性必须适当地设置为BOTH限制缓存的性能/大小。在投票周期之间充分覆盖饲料最旧的条目。缓存可以是内存驻留，数据库，文件系统或网络阵列。像EHCache这样的产品ehcache.org提供了所需的所有功能。
订阅源条目可以按原样保留，但最好（最有效）的方法是识别使其唯一的内容或其组合。诸如java中的序列化或Google的协议缓冲区之类的方法可用于创建唯一的紧凑密钥以在缓存中持久存在。在我的简单解决方案中，我甚至不打算存储条目，只是作为几个输入字段的MD5哈希生成的密钥，我通过该字段定义了条目对于我的目的而言是唯一的。
希望flowchart有用。